Don't Panic — Unit and Integration Testing

Automated testing is a way to turn a claim about software into something the build can check repeatedly. It is not a certificate of universal correctness, sadly. It is evidence about the behavior somebody had the good sense to name before a change made it mysterious.

The first useful split is unit test versus integration test. A unit test keeps its attention on one unit of work under the team's control. A canceled order must not become paid, for example. Give it the required state, ask for payment, and check for the defined error. The database, network, clock, and other travelling circus stay outside the tent.

An integration test points at a seam: the place where independently sensible parts must agree. An application and a database must agree about a schema. An HTTP adapter and another service must agree about a message. A test can be perfectly correct about a pricing rule while having absolutely no idea whether its SQL works. Both facts can be true. Software is very accommodating that way.

Test doubles help keep this boundary honest. A stub returns prepared data. A fake is a small working replacement. A mock checks an interaction when sending that interaction is itself the requirement. They are not miniature copies of every dependency. Once a test starts reenacting private helper steps, it has begun testing the furniture arrangement rather than the house.

The surprising part is that a bigger test is not automatically better evidence. Broad user journeys matter for critical wiring, but they usually cost more to run and explain. A portfolio keeps many focused unit checks close to the rules, selected integration checks near important seams, and only a few broad journeys. The risk and the feedback cost choose the mix; a geometric shape does not get a vote.

Passing tests only speak for the behavior they exercised. A flaky test, one that changes result without a material product change, speaks in static. Control time, random values, identifiers, and test data. Wait for a defined completion condition instead of a fixed sleep. Then a failure can say what happened rather than merely announcing that something somewhere has developed feelings.

Read the Intro for the full boundary map and the glossary. Use Slides when the portfolio and seam relationships need a quick visual pass. Keep the Cheatsheet beside the test code for doubles, assertions, and diagnostic signals. Then use the Practice Reference to turn one behavior and one seam into evidence you can trust.