Testing from the first commit
Why we write tests alongside the first lines of a product, and where we deliberately don't.
Testing is easiest to skip at the start, when everything is small and you can hold the whole system in your head. It is also cheapest to do at the start, for exactly the same reason.
Test what would hurt people first
We don't begin by chasing a coverage number. We begin by listing the things that would genuinely hurt someone using the product if they broke: saving their data, signing in, the core action the product exists for. Those paths get tests first, and they get the strictest ones.
Small iterations, always working
We build in focused iterations and keep a working build at every step. A test suite that runs on every change turns "did I break something?" from a worry into a fact. It also makes it safe to refactor, which is what keeps a codebase healthy over years rather than months.
Tests are documentation that can't go stale
A comment can drift out of date without anyone noticing. A test that no longer matches the code fails loudly. When someone new opens a module, the tests are often the quickest honest description of what it is supposed to do.
Where we don't over-test
- Throwaway prototypes. If the goal is to learn whether an idea is worth building, we keep the prototype disposable and write the real tests when we commit to the real thing.
- Pure presentation details. We lean on design review and real devices for pixel-level polish instead of brittle visual tests.
- Things the platform already guarantees. We don't re-test the framework.
The habit matters more than the tool
Which test runner we use is a detail. The habit is the point: nothing is considered done until we know how we would find out it had broken.