Testing and Validating Your Code
Dividing a long program into functions allows you to debug the parts one at a time and then assemble them into a working whole.
A Smaller Search Space
When a long program fails, the error could be in input validation, a calculation, output formatting, or the way several steps interact. If the program is one continuous block, you may need to trace through the entire sequence to discover which part went wrong. Dividing the program into functions creates smaller units that can be tested separately. This changes debugging from an open-ended search into a systematic process.
The purpose of independent testing is not to keep functions separate forever. It is to verify each piece first, so that later debugging can focus on how the pieces interact.
Testing One Function
Independent function testing follows a deliberate sequence. First, define the function. Next, choose known test inputs. Call the function with those inputs, observe the output, and compare that output with what you expected. If the actual output is wrong, the function being tested becomes the immediate focus of the investigation. If the output is correct, you can move to the next function with more confidence.
Document both the expected output and the actual output. Test edge cases as well as ordinary inputs, and fix a discovered bug immediately rather than moving on while the result is still uncertain.
Why Modularity Helps
Testing a complete program at once leaves many possible causes for a failure. The error could originate in any function or in the way the functions interact. Testing each function independently eliminates the first category of possibilities: once a function has been tested and verified, it is less likely to be the source of a later integration failure. The remaining investigation is therefore focused on the interaction between functions.
From Pieces to Program
A Generated Testing Sequence
Imagine a program divided into three functions: one for input validation, one for calculation, and one for output formatting. How can you test the program systematically?
Test input validation: Choose known inputs and verify that the validation function produces the expected outputs. Record the expected and actual results.
Test calculation: Call the calculation function with suitable known inputs and compare its output with the expected result. Fix the function immediately if the result is wrong.
Test output formatting: Give the formatting function a known result and check whether its output matches the expectation. Include edge cases where appropriate.
Integrate the functions: Assemble the functions into the larger program only after the individual tests provide confidence in each piece.
Investigate integration failures: If the complete program now behaves incorrectly, focus first on how the functions interact rather than reopening every individual function as an equally likely suspect.
Independent testing verifies the pieces first and makes an integration failure easier to narrow down.
The sequence matters. Testing the complete program first gives you a failure but does not identify its location. Testing the functions separately creates a record of which pieces have already been checked. After integration, a new failure has a more limited set of possible explanations: the functions may interact incorrectly, or the integrated execution path may not behave as expected.
Mistakes That Hide Bugs
Testing only the complete program
The failure could come from any function or from their interaction, so the search space remains large.
Fix:
Test each function with known inputs before assembling the complete program.Skipping edge cases
A function may appear correct for ordinary inputs while behaving incorrectly at an edge case.
Fix:
Include edge cases when choosing test inputs.Moving on after finding an incorrect result
The uncorrected result makes later tests harder to interpret and weakens confidence in the assembled program.
Fix:
Document the difference, fix the bug immediately, and then test again.Checking only the final result
You cannot easily tell which step failed.
Fix:
Verify the output of each function independently.
Practice the Workflow
A long program has three logical parts: input validation, calculation, and output formatting. The final output is incorrect. Describe the order in which you would test these parts and explain what information each test would give you.
Hints
- Start with one function rather than the complete program.
- For each function, choose known inputs and write down the expected output before observing the actual output.
- If an individual function is correct but the integrated program fails, consider the interaction between functions.
Key Takeaways
- Dividing a long program into functions makes it possible to test and debug smaller parts independently.
- Independent testing consists of defining a function, choosing inputs, calling it, observing its output, and verifying the expected result.
- Testing edge cases and recording expected versus actual outputs improves the quality of validation.
- After individual functions are verified, integration bugs are more likely to involve interactions between functions rather than the functions themselves.
- Fixing problems immediately creates a tight feedback loop and narrows the search for remaining bugs.