The user base for TcUnit, the free open-source PLC/TwinCAT unit testing framework, has grown enormously. Current estimates are that there are over 100 installations of TcUnit worldwide. Running an open-source project has for some moments taken all my spare-time to maintain the framework, and answer all the questions from the users (I’ve added an FAQ since). The most asked-for functionality of TcUnit that was missing was the possibility to run unit tests in a sequence/in order. Up to now, all tests defined in TcUnit were running in parallel, while in many use cases it was desirable to run the tests in sequence. Thanks to several fantastic contributors from the TcUnit community on GitHub, this is now available in TcUnit starting from version 1.2.
This is a joint article by me and Peter Kurhajec.
Unit testing is the practice of writing a test for a required functionality. In the world of “classical” IT software development, the concept of unit testing has been around for almost two decades. What is a standard procedure in languages such as Java, C++, .NET/C#, Python, etc. — has been completely lacking in the world of PLCs. The world of automation did not have the proper tools, and nor did it develop any comprehensive automated testing frameworks. Here we present two possible approaches for unit testing in Beckhoff’s TwinCAT 3.
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.
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.
Sharing knowledge with other TwinCAT developers using a blog is not only an easy and good way, but it’s also quite fun. After a long day at work, I often find it enjoying to sit down and write a little bit on a new blog post. Quite recently I launched TcUnit – the TwinCAT unit testing framework and even though there now is tons of documentation and example code on the official website, some people prefer to learn by watching a video. For this reason I’ve created a series of four videos that will introduce TwinCAT software developers to test driven development (TDD) and how to do TDD using TcUnit.
I’m very happy to announce the release of TcUnit – an unit testing framework for TwinCAT3. TcUnit is an xUnit type of framework specifically done for Beckhoffs TwinCAT3 development environment. This is another step in the direction of modernizing the software development practices in the world of automation.
Before dwelling into the details, let me tell the background of this project. In 2016 the development of the CorPower wave energy converter (WEC) was in an intensive phase. Software was being finalized, tested and verified for delivery. In a late phase of the project some critical parts of the software needed to be changed. The changes could be isolated to a few function blocks (FB), so in an initial phase the tests simply consisted of exporting those FBs to a separate project and running them locally on the engineering PC. The FBs were changed and executed in the engineering environment, and then online-changing the inputs and seeing whether the expected outputs were given. After doing this for a couple of hours an important question was raised:
Shouldn’t this be automated?
In my earlier posts I’ve written about development of TwinCAT software using test driven development (TDD), by writing unit tests. One of the advantages by adhering to the process of TDD is that you mostly will end up with function blocks (FBs) which have limited but well defined responsibility. Eventually you will however have FBs that are dependent on other function blocks. These could be FBs that are your own, or part of some 3rd party library, for example a Beckhoff library. Further, what if this external FB relies on some other functionality such as external communication using sockets that we have no control of? The external FBs should already be tested, we’re only interested in making sure our unit tests test our code! What do we do? A solution to this is to mock the external functionality and use dependency injection.
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.
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.
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.