For long time, we have been performing automated tests of our OPC client libraries. This is basically a combination of unit tests and integration tests, and we have developed these tests along with the products themselves.

This year (2013), however, we have been been going through the OPC compliance certification procedures for OPC Unified Architecture (OPC-UA) with our QuickOPC product, and a new area of tests has emerged. The OPC Foundation provides a Compliance Test Tool (CTT) that allows testing of both OPC servers and clients. It is a script-based engine and GUI. For client testing, the original design of the CTT assumed that the tester would manually enable certain scripts in the CTT (such as for error injection), then run the sequence of operation in the client, and observe and evaluate the results (both in the client and in the CTT) to see if everything went as expected.

This process gets VERY tedious over the time. Consider the facts that there are hundreds of tests in the basic CTT suite, that they are (at least sometimes) quite complicated to set up, and that the whole testing process needs to be repeated over and over, for regression testing. It seems that nobody has really gone through this for the OPC client testing so far. In fact the CTT test script themselves are not yet finished, and we have contributed multiple improvements and bug fixes to the OPC Foundation during our work. Even with the corrected scripts, it was not feasible to perform this kind of testing manually. We have therefore suggested a handful of changes to the CTT tool (engine) itself, and OPC Foundation has implemented them, with us being the reviewer.

What is the end result? Well, now we can - and YOU can as well (if you have access to the CTT tool - currently for OPC members only) automate the testing of OPC-UA client applications. Basically, the CTT provides a command-line interface that allows you to start it, and let it run a specific script inside the engine. Your test code can do it automatically, and then invoke the necessary client actions, and verify the results. In addition, the command line parameters will allow you to save the results (as seen in CTT GUI) into a file, and this file can be inspected automatically as well.

This way, the tests that are using the CTT can be integrated directly into whatever test runner you use - for example, Visual Studio, NUnit, or ReSharper. We have made a video about this. The video file for download is available here.

If you want to do something similar, the command-line parameters we are using with the CTT are:

• --settings ProjectFile
• --file ScriptFile
• --result ResultFile
• -k

The -k parameter make the CTT to keep the TRACE.DAT file containing data about the OPC communication.