How do big-bang, top-down, bottom-up and sandwich integration strategies differ in ordering and cost?

## Two decisions hiding in one word "Integration strategy", in the classic testing literature, names the order in which separately built components are joined and tested together. It answers two questions at once: whether components are joined **all at once or incrementally**, and if incrementally, **in which direction** — from the top-level components downward, from the foundational ones upward, or from both ends at once. The vocabulary predates continuous integration and is often examined in certification-flavoured interviews, so it is worth being able to state cleanly even where the formal ceremony no longer applies. ## Big-bang integration Every component is developed separately, then assembled and tested together in one step. Its appeal is that nothing extra has to be written: no stand-ins for the parts that are not ready yet, no harnesses to call the parts that have no caller. Its cost lands entirely at the end. The first run usually produces many simultaneous failures with heavily entangled causes, and because everything changed at once there is no small recent delta to blame. Localisation is the expensive part, and it arrives at exactly the moment in a project when there is least time for it. ## Top-down integration Start with the highest-level components and integrate downward, level by level. Components not yet integrated are represented by **stubs** — minimal stand-ins that return canned responses so the caller can run. - *Buys*: the overall control flow and the high-level interfaces are exercised early, so architectural and interface misunderstandings surface while they are cheap to change. A demonstrable skeleton of the product exists early. - *Costs*: many stubs, and stubs are not free — a stub rich enough to drive interesting paths starts to need its own maintenance. Defects in the foundational components arrive late, and those are frequently the ones with the most far-reaching consequences. ## Bottom-up integration Start with the lowest-level components and integrate upward. Components above that do not exist yet are represented by **drivers** — small harnesses whose only job is to call the component and check what comes back. - *Buys*: foundational components are exercised early and thoroughly, and drivers are usually simpler to write than equivalent stubs. - *Costs*: no working end-to-end shape exists until late, so high-level design faults and misread requirements surface last. Stakeholders have nothing to look at for a long time. ## Sandwich, or hybrid, integration Work from both ends toward a middle layer: top-down from above and bottom-up from below, meeting in the middle. It shortens the wait for both classes of defect — high-level flow and foundational behaviour — at the price of building both stubs and drivers, and of a more complicated plan that someone has to keep honest. It is the pragmatic choice on large systems with a clear layering. ## A worked ordering choice A marketplace bidding engine is built as three layers: an auction-orchestration layer, a bidding layer and a persistence-and-messaging layer. Ordering matters because the two riskiest unknowns sit at opposite ends — whether the auction state machine is right, and whether bid amounts survive storage. Top-down alone would leave the amount-format defect until last; bottom-up alone would leave a misread closing rule until last. A sandwich order, joining orchestration downward while persistence is joined upward, brings both into a 340-case regression pack far earlier, at the cost of maintaining stubs for the bidding layer and drivers over persistence for a few weeks. ## How this reads in a continuously integrated codebase Where every change is merged and tested continuously, nobody writes an integration plan naming these four strategies. The distinction still survives as an argument about sequencing: a team that merges everything and only then tries to make the assembled thing work is doing big-bang integration with a modern vocabulary, and it fails in exactly the documented way — many entangled failures and no small delta to blame. The incremental strategies survive as the instinct to join one component at a time against something real, and to keep the number of simultaneously unknown parts to one. ## What an interviewer is listening for The pairing of direction and stand-in type is the load-bearing detail — top-down uses stubs beneath, bottom-up uses drivers above — and the corresponding statement about **when defects arrive**: top-down finds interface and control-flow faults early and foundational faults late, bottom-up the reverse. A candidate who can also say why big-bang is cheap to plan and expensive to diagnose has the whole idea. This is a vocabulary question rather than a screening one, and not knowing the four names says little about whether someone can integrate a system; being able to explain the trade-off in terms of defect arrival time says quite a lot.