Question 3 of 8: Testing Strategies, Drivers, and Stubs

Question 3: Testing Strategies, Drivers, and Stubs (10 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

(a) Testing strategies for a large system

A large system is normally tested in four escalating strategies, moving from the smallest testable unit to the deployed whole: unit testing exercises one module/function in isolation against its own design, using white-box techniques (Question 4/6) to check internal logic; integration testing combines already-unit-tested modules incrementally — top-down (start at the top of the call hierarchy, replace unwritten lower modules with stubs), bottom-up (start at the leaves, drive already-built lower modules with drivers, matching Appendix A's own hierarchy in Question 6), or sandwich/hybrid (both directions meeting in the middle) — specifically to catch interface and data-passing defects that unit testing, by definition, cannot see; validation testing checks the fully integrated software against the customer's stated requirements, typically black-box, and includes alpha/beta testing (Question 7b); and system testing checks the software's behaviour once integrated with its full real-world environment (hardware, other systems, users) under recovery, security, stress, and performance conditions that a single application cannot exercise on its own.

Compared and contrasted: unit and integration testing are largely the developers' responsibility and focus inward, on the code's own structure and interfaces; validation and system testing are closer to the customer's perspective and focus outward, on whether the right product was built and whether it survives its real operating environment. Each strategy is a necessary but not sufficient check — a system can pass every unit test and still fail integration (interface mismatch), pass integration and still fail validation (wrong requirement implemented correctly), or pass validation in isolation and still fail system testing under real load.

(b) Test drivers and test stubs

A test driver is a small "harness" program that calls the unit under test, supplying it with test-case input data and reporting/comparing its results — it substitutes for a caller that does not yet exist. A test stub is a skeletal, dummy replacement for a module that the unit under test itself calls — it substitutes for a callee that does not yet exist, returning canned/minimal results just sufficient to let the caller's own logic execute.

Both exist for the same reason: to let a module be exercised in isolation before every other module in the system has been written. Their use differs by testing strategy: pure unit testing uses both a driver (to invoke the unit) and stubs (for every module it calls), since neither side of the unit is assumed to exist yet. Top-down integration uses stubs extensively (lower modules are progressively replaced by real code as integration proceeds downward) but needs no driver, since the top module is the real entry point. Bottom-up integration is the mirror image — it uses drivers extensively (to invoke the already-built lower modules before their real caller exists) but needs no stubs, since the leaves are already-built real code. For Appendix A specifically (Question 6), DisplayMenu() and GetAnswer() have no callees of their own, so they can only need a driver; DisplayProps() and SearchProps() likewise call only library I/O, so they too need only a driver to unit-test in isolation; only main(), which calls all four, would need stubs in place of them if it were tested before they existed.