When all units pass and the app still breaks
Here is the trap that makes integration tests necessary. Component A is tested with doubles: green. Component B is tested with hand-built inputs: green. But A's real output and B's expected input disagree, maybe just a dictionary key spelled differently. Every unit test passes and the assembled program crashes on its first real run.
An integration test closes that gap by running the real pieces chained together, no doubles at the seam:
order = parse_order(line) # real A total = order_total(order) # real B, fed A's real output
You need far fewer of these than unit tests, one per important seam, because the units already cover the edge cases inside each piece.
The example below feeds the seam a CSV line — short for comma-separated values, the plain-text format where each record is one line and commas separate the fields, like notebook,3,4.50. CSV is the most common way tabular data moves between programs, which makes a CSV parser feeding a calculator a very realistic seam.
Code exercise · python
Run this healthy integration test: a raw CSV line flows through the real parser into the real total function, and the seam holds.
Quiz
In the block above, what makes test_integration_line_to_total an integration test rather than a unit test?
Code exercise · python
Your turn. Someone renamed a key in parse_order and the unit test still passes, but the integration test now crashes with KeyError. Run it, read the error, and fix the seam so both tests pass. The team's agreed contract for the key name is unit_price.
Problem
Your team has 900 unit tests, 90 integration tests, and 9 end-to-end tests. A new rule has twelve numeric edge cases around a boundary. At which pyramid level do those twelve probes belong?
Quiz
New requirement: parse_order must raise ValueError on a line with a missing quantity, like "notebook,,4.50". Where does that test belong?