Don't Panic: Unit Testing

Unit testing is a small automatic argument with your code: given this known situation, does this one behavior still keep its promise? It exists because checking everything by clicking through an application is slow, vague, and has an unfortunate tendency to discover defects only after lunch.

The central trick is Arrange, Act, Assert. Arrange the smallest useful setup. Act once on the behavior. Assert the result a caller can observe. That result might be a returned value, a state change, a handled error, or a charge request sent to another component. The test runner delivers the verdict, which is kinder than recruiting a human to interpret a wall of output.

The other crucial idea is the unit boundary, the part of the system kept under control for this check. A database, network call, filesystem, clock, or random source can answer a different question from the one you meant to ask. That does not make those things villains. It means they belong in integration tests when the real seam is the risk. Unit tests are fast evidence for component rules, not ceremonial proof that the whole application has achieved enlightenment.

Controlled collaborators are called test doubles. A stub returns prepared data. A fake is a small working replacement. A mock verifies a required interaction. The surprising part is that a mock is not automatically more thorough. If callers care about a value, assert the value. If the contract requires one charge request, assert that request. Recording every private helper call merely teaches the test the current plumbing diagram, which is very loyal until the plumbing changes.

Coverage is another number with a job and a tendency to be asked to do someone else's job. It reports executed code. It cannot tell whether an assertion matters or whether the risky behavior is missing. A flaky result has a similarly awkward message: something outside the intended behavior is still in charge. Control time, randomness, order, and asynchronous completion instead of retrying the ambiguity into submission.

Read the Intro for the full boundary and test-double map. Use Slides when you want the relationships compressed into decisions. Keep the Cheatsheet nearby while writing a test, then take the exercise when one approval rule needs a proper, observable contract. The quiz checks whether the vocabulary has stopped behaving like a crowd of suspiciously similar acronyms.