Integration, regression, smoke, validation, acceptance, and specialized testing

The interfaces are the product

Components that each pass their unit tests routinely fail when assembled, because the defects of assembly are not defects of components: data is lost or misread across an interface, one component disturbs another's state, subfunctions that are individually correct do not compose into the major function, and individually acceptable imprecision accumulates past tolerance. Integration testing is the systematic construction of the program structure while testing for exactly those errors. The tempting alternative — combine everything and test the result — fails for a precise reason: with the whole program present a symptom can originate anywhere, so the cost of localising each defect scales with the size of the system rather than the size of the increment. Incremental integration keeps that cost bounded, which is the entire argument.

Top-down and bottom-up

Top-down integration starts at the main control module and moves downward through the control hierarchy, depth-first or breadth-first, replacing every not-yet-integrated subordinate with a stub. Its advantage is that the major control decisions — where design errors are most expensive — are exercised first, and a demonstrable skeleton of the program exists almost immediately. Its costs are real too: low-level function is not exercised until late, and a stub returning a fixed answer can hide the work it stands in for, so a test can pass for the wrong reason.

Bottom-up integration starts with the atomic modules, groups them into clusters that implement a subfunction, and exercises each cluster with a driver — a throwaway program that calls into it with test data. No stubs are needed, because everything below is already there, and low-level function is proven early. The cost is symmetric: there is no working program until the last cluster is joined, so nobody can demonstrate the system until the end. Real projects usually run a sandwich of the two, which is a legitimate exam answer provided you say why for the project in front of you.

Continuous integration and the daily smoke test

Smoke testing rebuilds the product with the day's newly completed components and drives it end to end, every day. It is not quick testing — it is a pacing mechanism that forces integration at a known rhythm rather than when someone gets around to it. Four benefits are claimed and all four are checkable — integration risk is minimised because breaks surface the day they appear; end-product quality improves because the assembled system is exercised constantly; error diagnosis is simplified because yesterday's build passed, so today's code is the prime suspect; and progress is easy to assess, because the smoke suite passes is a fact rather than an opinion.

Regression testing

Regression testing re-executes a subset of already-passed tests to confirm that a change has not damaged previously working behaviour. It is not re-testing a fix, which confirms one specific defect is gone; regression protects everything the change was not supposed to touch. The suite is conventionally built from three parts: a representative sample across all functions, tests focused on the functions most likely to be affected by this change, and tests on the components actually changed. As the full suite outgrows the time available, selection is driven by change impact analysis, traceability and historical defect data.

Validation, acceptance, and specialized testing

Validation testing begins where integration ends. It works only in terms of user-visible actions and output, and succeeds when the software behaves as the customer reasonably expects. It produces a deficiency list of everything that deviates, and it is accompanied by a configuration review confirming that every element of the configuration is present, catalogued and complete. Acceptance testing is then run by the customer: alpha testing at the developer's site with the developer present and recording, in a controlled setting; beta testing at the customer's own sites with the developer absent, in live use, with problems reported back. Alpha is controlled but narrow in environment coverage; beta is uncontrolled but broad, which is why it finds configuration defects nothing else does. Beyond this sit the specialized forms: security, performance (load, and stress past the design point), real-time, mobility and accessibility testing.

Worked example — the BorrowBox integration plan

BorrowBox's structure argues for a strategy rather than a favourite. The riskiest element is the locker vendor's SDK, which the team does not own, and the atomic modules underneath it — fee calculation, token issue, reservation state — are small and independently valuable. So: bottom-up for those clusters, each with a driver, because their correctness can be proven now instead of in six weeks; and a single hand-written stub for the vendor SDK that opens a simulated door, so nothing waits on hardware. On top of that, continuous integration with a daily smoke run over reserve → collect → return → settle fee against the simulator, plus a twice-weekly run against two real lockers on a bench. Regression selection uses the traceability matrix: touching the grace-period constant pulls in the fee tests, the token-expiry tests and — the one people miss — the shared clock utility both depend on. Validation then runs against the seven release stories with a member in the room, and its deficiency list is what the go/no-go decision is actually made on.