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.
We are at the final post of this series of continous integration and delivery with TwinCAT. We’ve accomplished setting up & configuring the automation server, created a TwinCAT test library project and wrote a small batch script that will be launched every time a new push has been done to the GIT repository for the library project. Now it’s time for us to write the program that will do the actual static code analysis.
In the previous post we did some installation and configuration of software to support us in the automation of doing static code analysis of TwinCAT software. We have reached a state where a Jenkins job is launched as soon as our TwinCAT library project is pushed to the GIT-repository. Even though we have a Jenkins job defined for static code analysis of TwinCAT software, it’s not doing anything yet. This will be our next step.
In the previous post we were introduced to the concept of continous integration and
continous delivery (CI/CD) in the world of PLC software development, more specifically TwinCAT development. The conclusion is that certain processes in the process of creating software can and should be automated. As an example, we set the goal of automating static code analysis of all TwinCAT software. In this part of the series of CI/CD we will look into some practical matters of installing and configuring the necessary software.
The development of PLC software needs to enter the 21st century. With the increased complexity of developed systems, the amount of software that is going to be developed for a given system will continue to increase. PLC development is partially living on an isolated island, and while most other areas of software development have been modernized, the world of PLC software engineering development is going significantly slower. When we develop more software, there is a need for more automation to remove unecessary manual handling and in the end increase the quality of the software we develop. Now I know that you can’t compare developing software for a web shop with developing software for a PLC that can run software that is critical and maybe even be safety-critical and one line of code can be the difference of life and death. However, developing reliable and robust software and adhering to modern software development processes and tools does not mean they do rule each other out. You can pick both.