When to Write Tests and When Not To: A Pragmatic View

Most teams either over-test or under-test, and both are expensive. Over-testing wastes engineering hours on tests that never catch real bugs; under-testing creates the kind of fear that slows down every refactor for years. The goal is to test the things that genuinely earn it.

Tests serve three real purposes

1. Regression safety — confirms a known bug doesn't come back.
2. Refactor confidence — lets you change implementation without breaking behaviour.
3. Documentation — shows future readers (including you) how a piece of code is meant to be used.

If a test doesn't serve at least one of these, it isn't earning its keep.

What deserves a test

Pure business logic

Pricing rules, tax calculations, eligibility checks, state machines. These are the rules that, when wrong, cost real money. They are also usually pure functions — easy to test, fast to run, hard to break flakily.

Data transformations and boundary code

Anything that maps from one shape to another (API → DB, DB → API response, CSV → records). These are the loci of subtle bugs ("oh, we mapped null to empty string by accident") and the easiest places to add value.

Bug fixes

Every time you fix a bug, write the test that would have caught it before merging. That test is the highest-value test you'll ever write — you literally know it catches a real bug, because it just did.

Critical integrations

Auth flows, payment flows, webhook handlers. Not because the unit tests catch much (they don't), but because integration or end-to-end tests give you a smoke alarm when an upstream changes its API.

What usually doesn't deserve a test

Trivial getters and setters

If your test file is full of expect(getName()).toBe('foo'), you are testing the language, not your code.

Throwaway code

Internal admin scripts, one-off data migrations, prototypes. If the code will be deleted in two weeks, a test on it is dead weight.

UI implementation details

Tests that assert on specific class names or DOM structure break every refactor. Test the behaviour the user sees, not the markup it produces. React Testing Library and Playwright user-flows are usually the right level.

Code you don't own

Don't test the framework, the library, or the language. Their maintainers have already done that.

The pyramid is upside down for most teams

The classic test pyramid (lots of unit tests, fewer integration tests, very few e2e tests) is sound advice for very large engineering organisations. For a 5–10 engineer startup we usually flip it:

• A small number of high-value e2e or user-flow tests covering the critical paths: signup, login, payment, the core product workflow. These catch the bugs that actually hurt customers.
• A medium number of integration tests covering the messy bits: external API calls (with mocks), database queries, complex business logic.
• Unit tests for genuinely pure functions — pricing rules, validators, parsers.

The reason: at small team size, you don't have the engineering hours to maintain a thousand unit tests. You do have the hours to maintain twenty user-flow tests that genuinely catch regressions.

What about TDD?

TDD (test first, then code) is great when the requirements are well-specified and the design is constrained — pure functions, algorithms, data transformations. It is much less useful when you are exploring product ideas where the right design isn't yet known. Don't religiously TDD an experiment; do religiously test the code that came out of the experiment once it earns its place in your codebase.

The metric that actually matters

Stop tracking line coverage. Track regressions caught in CI before they hit production. If your test suite catches one bug a quarter, the suite is earning its keep regardless of coverage percentage. If it catches nothing for a year, your tests are testing the wrong things.

Tests are a tool, not a virtue. Use them where they pay back, skip them where they don't, and judge the suite by what it prevents — not by how much of it there is.