Test driven development with YAKINDU Statechart Tools’ SCTUnit

Information: YAKINDU Statechart Tools Is Now itemis CREATE
Recently we had a discussion about Test Driven Development. Is it really important or just a buzzword. We agreed quickly: it is not a Buzzword. TDD is a skill. You need to acquire it, you need to practice it, you need to do it. And you can do TDD on statechart models within YAKINDU Statechart Tools – with SCTUnit.

SCTUnit is part of the current YAKINDU Statechart Tools Standard Edition. With SCTUnit you can apply TDD within your model driven development process. As the following image illustrates usually we start with a failing test, fix the test by coding and refactor. Then the cycle restarts and we write the next Test. With YAKINDU Statechart Tools we write a test for the statechart model, then fix the model and refactor the model.

Test driven development wit YAKINDU Statechart Tools' SCTUnit

Let us practice this skill now for a simple traffic light model. We organize the tests within the regular project. So first we create a project with a folder ‘model’ and a folder ‘test’.

Then we create the first test. Within YAKINDU Statechart Tools this is called “SCT Unit Test Class”. It is a test file similar to a unit test class within other programming languages. The new file is already filled with the most important statements. It looks like this:

testclass initialTest for statechart trafficLight {
   @Test
   operation test() {
  
 enter

 exit
   }
}

The keyword testclass introduces a test class, a collection of tests. In this example, it is named trafficLight.

A test class always refers to a statechart that is under control and is to be tested. This relationship is established by the for statechart clause.

Now we create this test:

There is an error marker, so the test fails. This is because there is no statechart named trafficLight. So let us fix this:

Now the test is green again. We do not have much to refactor for now, so we create the next test. What behavior do we want to model? We start with a state Red. After 1 s it shall switch to Yellow and then to Green and then exit. For now we only model one traffic light cycle. Every statechart needs an entry and an exit state.

The test statement will look like the following:

enter
assert active (trafficLight.main_region.Red)
proceed 1 s

assert active (trafficLight.main_region.Yellow)
proceed 1 s

assert active (trafficLight.main_region.Green)
exit

You may know assert statements from other unit frameworks. Referring to state machines we assert that a certain state is active or not. First we want the Red state to be active. To identify the Red state we use an absolute path:

<nameOfTheState>.<nameOfTheRegion>.<nameOfTheState>

The proceed 1 s instruction orders the state machine to execute the state machine for 1 s. After this one second the Yellow state shall be active and so on. Finally the test leaves the state machine as indicated by the keyword exit.

This test fails; it does not even compile. So we are in the red phase of our TDD cycle. Let’s make it green and enhance the statemachine by two additional states and transitions.

The test compiles. Now let us run it. Similar to Junit or other unit testing frameworks we start it by selecting the test, right click, select Run as… SCTUnit test. You will see a view similar to JUnit.

Now we have a running model and a test and we can proceed with further development. Because we have the test(s) we can be sure that the statechart does what it should do. Another benefit is: we save time we used for simulating and testing the correct behavior manually. So try this feature out. It is part of the YAKINDU Statechart Tools Standard Edition you can freely use for non-commercial purposes.

I am interested in your experiences with SCTUnit and YAKINDU Statechart Tools. Please comment or write an e-mail to yakindu@itemis.de.

If you want to try YAKINDU Statechart Tools yourself – just download it!