Generating SCTUnit source code

Executing SCTUnit tests within the Eclipse development environment as described in section "Running the test" is a nice and handy feature for the developers. However, it all happens on the modeling level, a higher abstraction level than the actual source code you are likely generating from your statechart. You will probably want to test the generated source code as well, especially in any safety critical environments.

Generating unit tests as source code comes as a solution. Source code can be inspected, compiled, and integrated wherever needed.

This section explains how you can generate your SCTUnit tests as source code with YAKINDU Statechart Tools. Supported programming languages are C, C++, Java, Python as well as SCXML for Qt. The SCTUnit code generators translate the SCTUnit tests into a unit test framework of the target language. For example, the generated Java test code uses JUnit as its testing framework and Mockito for mocked methods. C and C++ sources rest upon the Google Test unit testing library.

In order to use the SCTUnit code generators effectively, you should already be familiar with generating source code from statecharts, as explained in chapter "Generating state machine code". In fact, you have to generate your statechart as source code first, so that the SCTUnit tests have something to be executed upon. Below we are assuming that you have your statechart code generator model and the generated code handy. Generating SCTUnit test source code follows the same principles as generating state machine source code, so we can focus on SCTUnit essentials here.

Creating a generation model

The first step is to create a generation model (SGen) for the SCTUnit test, similar to explanation in section "Generating state machine code".

  1. In the main menu, select File → New → Other…. The New dialog opens.
  2. In the New dialog, select YAKINDU SCT → Code generator model.
  3. Click on Next. The YAKINDU generator model wizard opens.
  4. Select a project and a folder as the SGen model’s location. The filename must end on .sgen.
  5. Click on Next.
  6. In the Generator drop-down menu, select one of the source code generators whose names begin with „SCTUnit”, e.g., „SCTUnit Java Code Generator”. As a consequence, the Choose list below the drop-down menu switches from showing statechart models to displaying SCTUnit files.
  7. In the Choose list, check the SCTUnit files you want to generate as source code.
  8. Click on Finish.

As a result, the SGen model file is created. Figure "A sample SCTUnit SGen model" shows a generator model for the SCTUnit Java generator. The target language is reflected in the generator ID „sctunit::java”. The generator IDs for C and C++ are „sctunit::c” and „sctunit::cpp”, respectively. Each SCTUnit test unit is contained in a section marked with the test keyword, followed by the respective fully-qualified test unit name.

A sample SCTUnit SGen model

A sample SCTUnit SGen model

In this example, the generation model refers to the SCTUnit sample test class defined in section "The package statement" above. In that example, the test class is put into package foo.light_switch.test, while the test class itself is named light_switch_tests. Consequently, the test class' fully-qualified name is foo.light_switch.test.light_switch_tests, and that is what the generation model indicates in the test statement.


A code generator’s behavior can be controlled by so-called features. SCTUnit code generators are supporting the same set of features the all statechart code generators support. The same applies to the features of the respective language-specific generators. The Outlet feature is of particular importance, since it determines where the generated artifacts will be created.

Documentation of feature details you can find here:

The SCTUnit Java code generator’s StatechartNaming feature

For Java, the generated state machine code on one hand and the SCUnit test classes on the other hand may well belong to different packages. However, in order to be able to execute the state machine, the SCTUnit tests need to know what the state machine’s package is.

This is what the StatechartNaming feature is good for. Let’s assume we added the following StatechartNaming feature to the generation model shown above:

feature StatechartNaming {
    basePackage = "bar.light_switch"
    implementationSuffix = ""
    libraryTargetFolder = "src-timer"

With these settings, the SCTunit code generator creates the test classes in the src-gen directory. Additionally, it creates a few timer classes. These classes provide the concept of „virtual” time and are used during test execution to simulate arbitrary long periods of time in an instant. The source code of these classes is generated in the directory denoted by the libraryTargetFolder property, here: src-timer. The timer classes belong to the bar.light_switch package. The test classes expect the timer classes and the state machine to reside in that very same package, in order to execute the state machine parameterized with the virtual timer.

The generated Java test class

The Java source code generated from SCTUnit test classes or test suites takes the form of JUnit tests and can be integrated in CI environments, for example.

In Eclipse, you can execute such a generated JUnit test by right-clicking on the corresponding .java file and selecting Run As → JUnit Test in the context menu.