The green phase is complete once the example code is fully functional. The refactoring phase involves refining the resulting code. For most projects, the refactoring phase will be a simple matter of tidying up. But for mission-critical TDD, the need to ensure that it will fulfil the objectives of functional safety or cybersecurity standards still remains.

The example code is now simple to maintain, fast and efficient, and ready for that refactoring phase to begin.

One of those objectives demanded by the functional safety standards might be to ensure that the code is not too complex. The example code has a McCabe cyclomatic complexity of 7, which is low (Figure 13). There are just 7 linearly independent paths through the code and so there is no need to refactor it to reduce the complexity.

Figure 13: Resulting code has acceptably low cyclomatic complexity

Other metrics such as the number of comments, exit points, fan in, and fan out might also be considered in this regard.

The code will also be required to comply with a coding standard, and the example uses MISRA C. A check on the code shows that two MISRA C rules have been violated (Figure 14).

Figure 14: Checking the example code for MISRA C compliance

The first MISRA C violation concerns an advisory rule. It can easily be resolved by simply moving the lookup table into the function itself. This makes sense, since it is only used by that function.

The second MISRA C violation concerns a required rule. In this instance it can easily be justified because, at this stage, only a single file is under analysis. Later on, when the entire system is analysed, the safe_sine function will be invoked and so that violation will not occur.

Functional safety and cybersecurity standards are also likely to require the application of code coverage analysis. The extent to which that is necessary would depend on the criticality of the application, but in the example it will suffice to confirm that the test cases have executed every statement and every decision.

A new sequence is created with just 6 test cases to cover each quadrant as well as the out of range values. Executing this sequence in a mode where the structural coverage can be measured confirms 100% Statement Coverage, 100% Branch /Decision Coverage and 100% MC/DC (Figure 15). All of the code has been executed.

Figure 15: Achieving adequate structural coverage of the example code

This sequence can be appended to the batch file, making it easy to regress all tests showing that the resulting code is compliant to MISRA C, the metrics are all within the specified thresholds, all the unit tests have passed, and 100% structural coverage has been achieved.

Sixth iteration: Refining the code (refactoring phase)