Question 4 of 8

Question 4 (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.

Part (a) — purpose of unit and integration testing. Unit testing focuses verification on the smallest testable piece of software — typically a single function, method or class — in isolation from the rest of the system, using stubs/mocks for anything it calls; its purpose is to catch logic, boundary and data-handling defects at the cheapest possible point, before that unit is combined with anything else. Integration testing takes units already unit-tested and combines them incrementally, with the explicit purpose of uncovering errors associated with the INTERFACES between units — parameter mismatches, incorrect assumptions about a called unit's behaviour, timing/ordering problems, and data that is corrupted crossing a module boundary — none of which a unit test (which exercises a module alone) can ever find.

Part (b) — sandwich integration testing. Sandwich (hybrid) integration testing combines top-down and bottom-up strategies simultaneously: the system's upper (control-oriented) layers are integrated top-down from the main control module downward, while its lower (utility/atomic) layers are integrated bottom-up from leaf modules upward, with the two integration fronts meeting somewhere in a middle target layer. Advantage over pure top-down/bottom-up: pure top-down needs many stubs to stand in for lower modules not yet built, and pure bottom-up needs many drivers to exercise leaf modules before any higher-level control exists — each defers a category of defect (top-down defers low-level logic defects; bottom-up defers architectural/control-flow defects) until late. Sandwich testing validates BOTH the high-level architecture and the low-level utility logic early and in parallel, needing far fewer throwaway stubs/drivers overall, and it lets separate sub-teams work the top and bottom fronts concurrently — shortening the integration schedule compared to either pure strategy.

Part (c) — main reason for regression testing. The main reason is to confirm that a change — a bug fix, a new feature, a refactor, or the addition of a newly integrated module — has not introduced new defects or re-broken functionality that was previously working. Because software changes are rarely fully isolated (a fix in one module can have side effects elsewhere via shared state, shared data structures, or unintended coupling), regression testing re-runs some or all of the existing test suite after every change specifically to catch these unintended side effects before they reach the customer.