12.3.3 Testing Code, Paths and Modules

12.3.3 Testing Code, Paths and Modules

Testing can begin before the complete system exists. Individual procedures and functions can be checked in isolation, temporary stubs can stand in for unfinished modules and knowledge of the code can be used to select inputs that execute important branches and loops.

Modules that work correctly on their own must then be tested together. Integration testing checks whether their interfaces, parameter values, return values and control relationships remain correct after they are connected.

Testing at Different Levels

A modular program can be checked at several levels. Each level provides different evidence.

Testing an Individual Module

Module testing is often called unit testing. The developer supplies controlled inputs directly to the module and checks its outputs, return value or changed reference parameters.

Questions to ask

• Does the module perform its stated responsibility?
• Does it accept the correct number and type of parameters?
• Does it return the expected value and data type?
• Does it handle every important internal branch?
• Does repetition process the intended number of items?
• Does it change only the data it is responsible for changing?
• Does it respond safely when a parameter violates an assumption?

Example module

FUNCTION ClassifyFloodRisk(
    BYVALUE WaterLevel : REAL,
    BYVALUE SensorWorking : BOOLEAN
) RETURNS STRING

    IF SensorWorking = FALSE THEN
        RETURN "SENSOR_FAULT"
    ELSE
        IF WaterLevel >= 4.8 THEN
            RETURN "EVACUATION"
        ELSE
            IF WaterLevel >= 3.1 THEN
                RETURN "WARNING"
            ELSE
                RETURN "NORMAL"
            ENDIF
        ENDIF
    ENDIF
ENDFUNCTION

This function can be tested directly without reading a physical sensor, saving a file or sending an alert.

White-box Testing

The tester examines how the module is written and chooses data that executes different parts of that code.

For ClassifyFloodRisk, the internal structure reveals four distinct return routes:

1. The sensor is not working.
2. The sensor works and the level is at least 4.8.
3. The sensor works, the level is below 4.8 and at least 3.1.
4. The sensor works and the level is below 3.1.

Statement, Branch and Path Coverage

Coverage describes how much of the internal program structure has been exercised by a set of tests.

Why statement coverage can be insufficient

IF WaterLevel >= 4.8 THEN
    Risk ← "EVACUATION"
ENDIF

CALL StoreObservation(Risk)

One test with WaterLevel = 5.0 executes every displayed statement, but it does not show what happens when the condition is false. In that case, Risk may not have been assigned.

Planning Tests from the Code Paths

A white-box tester can annotate each route through the module and then select the smallest useful set of data that reaches those routes.

A path-based method

1. Identify each decision.
2. List the possible outcome of each decision.
3. Combine outcomes into feasible routes.
4. Select input values that satisfy each route’s conditions.
5. Predict the result for each route.
6. Run the module and record the actual result.
7. Investigate any route whose result differs from the expectation.

White-box Testing of Loops

Loops create paths according to how many times their bodies execute. Useful tests should be chosen from the loop structure.

FUNCTION CountWarningReadings(
    BYREF Readings : ARRAY OF REAL,
    BYVALUE ItemCount : INTEGER
) RETURNS INTEGER

    DECLARE Index : INTEGER
    DECLARE WarningCount : INTEGER

    Index ← 1
    WarningCount ← 0

    WHILE Index <= ItemCount DO
        IF Readings[Index] >= 3.1 THEN
            WarningCount ← WarningCount + 1
        ENDIF

        Index ← Index + 1
    ENDWHILE

    RETURN WarningCount
ENDFUNCTION

Stub Testing

A stub uses the same interface as the intended module but performs only a small, predictable action. It may:

• display or record that it was called;
• record the parameter values it received;
• return a fixed test value;
• simulate a successful result;
• simulate a controlled failure.

Example alert stub

PROCEDURE SendEvacuationAlert(
    BYVALUE StationID : STRING,
    BYVALUE WaterLevel : REAL
)
    OUTPUT "[STUB] SendEvacuationAlert called"
    OUTPUT "Station: ", StationID
    OUTPUT "Level: ", WaterLevel
ENDPROCEDURE

This does not send a real warning. It allows the controller to be tested before the communication module has been completed.

Designing a Useful Stub

A useful stub must behave predictably and preserve the intended interface.

Function stub

FUNCTION StoreObservation(
    BYVALUE StationID : STRING,
    BYVALUE WaterLevel : REAL,
    BYVALUE Risk : STRING
) RETURNS BOOLEAN

    OUTPUT "[STUB] StoreObservation called"
    OUTPUT StationID, WaterLevel, Risk

    RETURN TRUE
ENDFUNCTION

Integration Testing

Two modules may pass all their isolated tests and still fail when used together. Integration testing concentrates on the interfaces between them.

Example module sequence

ReadObservation
        ↓ StationID, WaterLevel, SensorWorking

ClassifyFloodRisk
        ↓ Risk

StoreObservation
        ↓ StoredSuccessfully

SendEvacuationAlert
DisplayStatus

Integration testing checks that:

• the correct module is called;
• parameters are supplied in the correct order;
• data types and formats are compatible;
• return values are interpreted correctly;
• calls occur in the required sequence;
• failure results are passed to the module that must handle them;
• shared data remains consistent.

Common Integration and Interface Faults

Integrating Modules in Manageable Stages

Connecting all modules at once can make a fault difficult to locate. A more manageable approach is to add one tested module or small group at a time.

1. Test ClassifyFloodRisk in isolation. Use data for every return path.
2. Connect ReadObservation. Check that its output values arrive in the correct format.
3. Add a storage stub. Confirm that the correct station, level and risk are passed.
4. Replace the storage stub. Check both successful and failed storage results.
5. Add the alert stub. Confirm that it is called only for the evacuation path.
6. Replace the alert stub. Retest the complete communication path.
7. Add the display module. Check that every risk value has a recognised display result.
8. Repeat previous tests. Check that adding a new module has not broken an earlier connection.

Worked Example: Coastal Flood-Monitoring System

A coastal station records a water level and sensor status. The controller classifies the risk, stores the observation, sends an evacuation alert where required and displays the result.

Controlling procedure

PROCEDURE ProcessObservation(
    BYVALUE StationID : STRING,
    BYVALUE WaterLevel : REAL,
    BYVALUE SensorWorking : BOOLEAN
)
    DECLARE Risk : STRING
    DECLARE StoredSuccessfully : BOOLEAN

    Risk ← ClassifyFloodRisk(
        WaterLevel,
        SensorWorking
    )

    StoredSuccessfully ← StoreObservation(
        StationID,
        WaterLevel,
        Risk
    )

    IF StoredSuccessfully = FALSE THEN
        CALL DisplayStorageFailure(StationID)
    ELSE
        IF Risk = "EVACUATION" THEN
            CALL SendEvacuationAlert(
                StationID,
                WaterLevel
            )
        ENDIF

        CALL DisplayStatus(
            StationID,
            Risk
        )
    ENDIF
ENDPROCEDURE

Stage 1: Test the classification module

Stage 2: Use storage and alert stubs

FUNCTION StoreObservation(
    BYVALUE StationID : STRING,
    BYVALUE WaterLevel : REAL,
    BYVALUE Risk : STRING
) RETURNS BOOLEAN

    OUTPUT "[STUB STORE]"
    OUTPUT StationID, WaterLevel, Risk

    RETURN TRUE
ENDFUNCTION

PROCEDURE SendEvacuationAlert(
    BYVALUE StationID : STRING,
    BYVALUE WaterLevel : REAL
)
    OUTPUT "[STUB ALERT]"
    OUTPUT StationID, WaterLevel
ENDPROCEDURE

With StationID = "C-17", WaterLevel = 5.0 and a working sensor, the expected call sequence is:

ClassifyFloodRisk
StoreObservation("C-17", 5.0, "EVACUATION")
SendEvacuationAlert("C-17", 5.0)
DisplayStatus("C-17", "EVACUATION")

Stage 3: Simulate failed storage

Change the storage stub so that it returns FALSE. The controller should call DisplayStorageFailure and should not send an alert or display a successfully stored status.

Stage 4: Replace the stubs

Connect the real storage module first and rerun the successful and failed storage tests. Then replace the alert stub and repeat the evacuation path.

Recording Test Evidence

Even when the focus is code paths or module interaction, the test should record an expected result and the actual result.

Formal test strategies, complete test plans and normal, abnormal and boundary data are developed in 12.3.5.

Interactive: Code Path and Module Test Lab

Switch between white-box path planning, stub testing and integration testing. For each stage, choose the evidence or test action that best matches the code.

FUNCTION ClassifyFloodRisk(
    WaterLevel,
    SensorWorking
) RETURNS STRING

    IF SensorWorking = FALSE THEN
        RETURN "SENSOR_FAULT"
    ELSE
        IF WaterLevel >= 4.8 THEN
            RETURN "EVACUATION"
        ELSE
            IF WaterLevel >= 3.1 THEN
                RETURN "WARNING"
            ELSE
                RETURN "NORMAL"
            ENDIF
        ENDIF
    ENDIF
ENDFUNCTION

Common Mistakes and Misconceptions

Practice

FUNCTION AirQualityBand(
    BYVALUE Reading : INTEGER,
    BYVALUE SensorValid : BOOLEAN
) RETURNS STRING

    IF SensorValid = FALSE THEN
        RETURN "INVALID"
    ELSE
        IF Reading > 150 THEN
            RETURN "HIGH"
        ELSE
            IF Reading > 70 THEN
                RETURN "MODERATE"
            ELSE
                RETURN "LOW"
            ENDIF
        ENDIF
    ENDIF
ENDFUNCTION

Review