test driven development

Dear TwinCAT/PLC developers,

I’m very happy to announce the release of the TcUnit-Runner, an open-source tool for integration of TwinCAT unit tests into a CI/CD toolchain automation server such as Jenkins. When TcUnit, the TwinCAT unit testing framework, was released back in December of 2018 I would never have imagined how widespread it would get. Since then, I’ve received e-mails from PLC developers every week with questions, improvement suggestions or just gratitude for this open-source software. The TcUnit framework has found its way into the full range of projects ranging from small machines to multi-billion € projects. With this response, I would say that there definitely is a need for unit testing in the world of automation. The adoption of TcUnit into TwinCAT projects across the globe has motivated the further development of TcUnit. One limitation of the TcUnit framework was that it was only possible to run the unit tests locally on your development machine (or PLC), and thus needed to be run manually every time a change in the software was made. Modern software practices advocate that software development should adhere to the practices of continuous integration/continuous delivery (CI/CD), so that tests would be run automatically when committing changes to version control. Thus, TcUnit-Runner was developed.

Read more

TcUnit is a unit testing framework made specifically for TwinCAT3. It’s an open-source project released under a MIT-license. Since the launch of TcUnit the response from users has been overwhelming! I’ve received tons of feedback from individuals and automation engineers from both small and large companies. Judging by the sheer amount of e-mails received over the last half year I would say that there is a big need for a unit testing framework for PLC developers.

Read more

We’re finally at the last post of this series! Patiently we’ve written all our tests and done all our code that implements the required functionality and made sure that our code passes all the tests. But in the end of the day, despite all the theory and coding we want our code to run on a real physical device. Now it’s time for the favorite part of every PLC programmer, which is getting down to the hardware and micro controllers! Let’s get to the grand finale, and test our code on a real PLC, IO-Link master and IO-Link slave.

Read more

In part five of these series we started the implementation of the function blocks that we previously have done unit tests for. As we have our tests, we could verify that our newly implemented code did what it is supposed to do, and thus we made our code pass the tests. What we’ve got left is to do the implementation for three of the remaining function blocks. Once this is done, we have implemented all the required functionality that we’ve declared that our unit tests require us to.

Read more

In the last post of the series of unit testing in TwinCAT we finalized our unit tests, thus creating the acceptance criteria for the expected functionality for our function blocks. Now it’s time to do the actual implementation of the function blocks that we described in part 2 of these series. As we have our unit tests finished, we can anytime during our development run them and check whether the implemented code passes the tests.

Read more

In the previous post we defined the general layout of our unit tests, and also did the implementation of the tests for two of the five function block that we’re going to use to verify the functionality of parsing IO-Link events. What we’ve got left is to create test cases for the parsing of the text identity and the timestamp of the diagnostic event. Then we also want to have a few tests that closes the loop and verifies the parsing of a complete diagnosis history message.

Read more

In the last post of this series we were looking at a use case for a certain set of functionality, more specifically creating parser function blocks for the handling of IO-Link events. The result was a series of function blocks with defined input and output. In this post we’ll create the unit tests that will use the function blocks that we’ve started doing. Naturally, when defining the tests they will all fail as we don’t have the implementation code ready yet.

Read more

In my previous post I explained some of the benefits of using test driven development (TDD) while developing PLC software. This post is the second part of a series of seven, where we will look at a real use case scenario of writing test cases prior to doing the actual implementation. The scenario which I thought would be good for this is by creating a parser for IO-Link events. Shortly, IO-Link is a standardized point-to-point serial communication protocol used to communicate with sensors and/or actuators. It is not a fieldbus, but only takes care of the communication to the end device. As it’s a fully digital protocol that on top of process data also supports services such as events and parameterization, it’s standing well prepared for the Industry 4.0 thinking. One of the functionalities of IO-Link devices is that they can fire off events to the IO-Link master to notify that something has happened, for instance an alarm that something is wrong. To integrate these IO-link devices (slaves) into your EtherCAT network you need an IO-Link master, which usually allows you to connect 4 or 8 IO-Link slaves.

Read more

Test driven development (TDD) doesn’t seem to be all too common among TwinCAT-developers, which is a shame. From my experience, TDD has a strong foothold everywhere among developers, but TwinCAT? Not so much. And I don’t blame them. There are TDD frameworks for C++, C#, Ada, Python and basically any other language and/or development environment. Do a Google search on the web on any programming language/IDE and TDD and you get thousands of results. Do the same for TwinCAT and you’re on your own.

Read more