Integration tests
Checking that modules that are correct on their own work together: interface faults, the big-bang, top-down and bottom-up integration strategies, stubs and drivers, and integration with a real database.
- 26 cards
- 4 topics
- Free
The outline, topic by topic
Each topic is weighted the way the exam weighs it.
- Concepts
- Questions
- Sort and link
- Scenarios
A few cards from the deck
Integration test: what is it?
Show the answer
A test that checks that modules already correct on their own work together, especially at their interfaces.
It looks for faults between modules: a call with the parameters in the wrong order, the wrong unit, a different date format. They exist in no module taken alone.
The Invoice module calls the Pricing module, which is not written yet. To test Invoice alone, what must be written?
- A stub that replaces Pricing and returns a planned price
- A driver that calls Pricing in place of Invoice
- A driver that replaces Invoice and starts Pricing directly
- Nothing: Invoice can always be tested without Pricing existing
Show the answer
A stub that replaces Pricing and returns a planned price
Invoice calls Pricing: the called module is the one missing, so that is what you replace, with a stub. A driver would replace a missing caller.
In top-down integration, you write … for the modules below; in bottom-up integration, … for the modules above.
Show the answer
In top-down integration, you write stubs for the modules below; in bottom-up integration, drivers for the modules above.
You always replace what is missing: going down, the called modules are missing; going up, the calling modules are.
Stub: what is it?
Show the answer
A temporary module that stands in for a called module, not yet integrated, and returns answers decided in advance.
It lets you test the calling module before what it calls exists. It supplies the data, it computes nothing.
Two teams each deliver a module tested on its own. Assembled, they give a wrong trajectory: one supplies pound-force seconds, the other expects newton seconds. What is the nature of the fault?
- A calculation fault in one of the modules, which its unit tests should have found
- A performance fault: the modules exchange too much data between them
- An interface fault: each module is right according to its own unit
- A usability fault: the user of the system did not understand the screen
Show the answer
An interface fault: each module is right according to its own unit
This is the loss of the Mars Climate Orbiter probe, in 1999: a piece of ground software produced impulses in pound-force seconds, while the navigation software read them as newton seconds, the unit the interface contract called for. Each computation was right in its own unit; the fault exists only in the exchange between the two.