The starting point is to create some initial tests – the red phase. These test definitions will include the possible inputs, expected outputs, and a description of what each test is designed to achieve.

For this example a Comma Separated Values (CSV) file is created to hold those definitions (Figure 2). The first four tests check for angles that are out of range. There is no need to test every possible value that is out of range – only boundary values.

The remaining values are designed to test all integer values of angles from 0° to 360° inclusive.

Figure 2: In the example, a CSV file is used to list values associated with the test cases

A Test Case Template (TCT) is then created to define the structure of each of these tests and to specify the CSV file columns holding the angle, description, and value data (Figure 3).

The template also specifies that each test needs to execute in less than 75 cycles, and that the output should be accurate to ±0.1%.

Figure 3: Applying a test case template to the example CSV file

A python script combines the CSV file with the test case template file. Each entry in the CSV file instantiates the template, replacing the $(CSV) placeholders with the values from the specified column. The result is a sequence of 365 test cases.

Code is then required to allow the function under test to be compiled. For this example, the Keil µVision5 for ARM is deployed to create a simple project that includes the safe_math.c file and a simple main to allow an executable to be built. The function needs to return a value, and 0 is the selected default (Figure 4).

Figure 4: Creating simple code to allow the example function under test to be compiled

Next, the sequence of test cases is loaded into the unit testing tool. The GUI shows the description and as the I/O values for each test case. The description field has an important part to play in clearly explaining the goal of each individual test case (Figure 5).

Figure 5: Loading the sequence of tests into the TBrun unit test tool.

A test harness is automatically created and a build attempted. The Keil µVision5 compiler is used in the example, but the linker is limited to 16K and so the build fails. On many resource limited targets, the size of the generated test harness can exceed the available memory.

The solution is to split the sequence of test cases into numerous smaller sequences. Initially the number of test cases in the example is reduced from 365 to the first 36, ensuring an executable that is small enough to be built successfully. In practice, considerably fewer test cases are likely to be involved for many functions.

That executable is then automatically downloaded to the target using the Keil µVision5 debugger, executed, and the results uploaded from the target. As expected the majority of test fail because the function always returns 0. However, the first few tests all pass because the value 0 was expected (Figure 6).

Figure 6: As expected, most tests fail when the initial, simple code is tested

First iteration: Creating the test cases (red phase)