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.

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
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
In the
In the
In my
lopment (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.