Skip to main content

Why We Test

Building software is engineering — but unlike a bridge or a car, a software system keeps changing after it ships. New parts are added and old ones refactored all the time. Every one of those changes can silently break something that already worked. Tests are how you keep that from happening: an automated check that the requirements still map to a working delivery after each change.

The problem it solves​

Without tests, the only way to know a change didn't break anything is to check by hand — and manual testing does not scale. As a system grows, the surface you'd have to re-verify by hand after every edit grows with it, until it's no longer possible to do reliably. Tests turn that re-verification into something a machine repeats in seconds, every time.

What a test actually is​

  • A single test describes one expected behavior of the code in human-readable terms. It states one or more expected outcomes and reports a binary result: pass or fail.
  • A test suite is a collection of those tests, run together.

The value isn't any one test — it's the suite as a whole giving you a fast, trustworthy answer to "did I break anything?"

Tests as insurance​

Writing a test costs a little time up front to avoid a potentially large loss later. That framing is the whole ROI argument: the cost of not testing is almost always higher than the cost of the test.

A bug caught in development is cheap — you fix it while the context is still in your head. The same bug in production is not:

  • emergency debugging under pressure;
  • hotfix deployments;
  • customer-support cost;
  • lost user trust;
  • sometimes, legal consequences.

Widely cited figures put a production bug at 10–100x the cost of catching it in development. The exact multiplier is debated and hard to source — but the direction is not: the later a bug is found, the more expensive it is to fix.

What you get for it​

Beyond catching bugs before your users do, a good test suite:

  • documents how the code is supposed to behave;
  • gives you the confidence to refactor and improve without fear;
  • onboards new developers faster — the tests show intended behavior;
  • enables CI/CD — automated gates need automated checks;
  • lowers the stress of shipping new features.

The payoff​

Tests don't slow you down — past a small system size, they're what lets you keep moving. They convert "I hope this still works" into "the suite says it works," on every commit. That shift, from hope to evidence, is the point.

Sources: freeCodeCamp's Software Testing with Playwright course, and this video on why we test.