Structural testing in a nutshell

Based on what we just did, let me define a simple approach that any developer can follow (see figure 3.4):

1. Perform specification-based testing, as discussed.
2. Read the implementation, and understand the main coding decisions made by the developer.
3. Run the devised test suite with a code coverage tool.
4. For each piece of code that is not covered:a) Understand why that piece of code was not tested. Why didn’t you see this test case during specification-based testing? Consult with the requirements engineer if you need more clarity.b) Decide whether the piece of code deserves a test. Testing or not testing that piece of code is now a conscious decision on your part.c) If a test is needed, implement an automated test case that covers the missing piece.
5. Go back to the source code and look for other interesting tests you can devise based on the code. For each identified piece of the code, perform the substeps of step 4.

Figure 3.4 Applying structural testing in a nutshell. Arrows indicate the iterative nature of the process. The diamond represents the moment where the developer decides whether to write the test case.

The most important thing about this approach is that structural testing complements the test suite previously devised via specification-based testing. The code coverage tool is an automated way to identify parts that are not covered.

Just like the approach I proposed this one is meant to be iterative and not to restrain you to a single way of working. It is not uncommon to go back to the specification and devise additional interesting test cases.

Before I show another running example of structural testing and discuss how to pragmatically use it in our daily lives, the next section introduces the coverage criteria we use with this approach.