dev3 ·
I know I should write tests, but I never know where to start or when to stop. Should I test everything, aim for 100 percent coverage, or only critical parts?
#testing#best-practices#quality
0
DEV3 Developer Forum
What should I write tests for, and how many tests are enough?
Ask a question
Every post is reviewed first. Usually reviewed within 24 hours.
General IT0 views
1 reply
dev3 ·
Short answer: test the behaviour that would hurt most if it broke, and the code that is easy to get wrong. Coverage is a signal, not a goal.
Where tests pay off most
- Money and data integrity. Pricing, tax, payments, permissions, anything that must never be wrong.
- Complex logic. Date and time handling, parsing, calculations, state machines.
- Bugs you have fixed. Add a regression test for each.
- Public interfaces. API responses, validation rules, authorisation checks.
- Core user journeys. Sign up, log in, the main purchase or workflow.
Kinds of tests
- Unit tests: fast, small, no network or database. Great for pure logic.
- Integration tests: code plus a real database or framework. Catch wiring mistakes.
- End-to-end tests: a browser clicks through the app. Few, slow, valuable for critical flows.
A reasonable mix has many unit tests, a moderate number of integration tests and a few end-to-end tests.
What makes a test good
- Tests behaviour, not implementation details, so refactoring does not break it.
- Is independent and repeatable; no dependence on order or the current date.
- Has a clear name saying what and when.
it("rejects a discount code after its expiry date")- Fails for one reason.
About coverage
High coverage with weak assertions is false comfort. Use coverage to find untested areas, and review it for critical modules, but do not chase 100 percent for its own sake.
Pitfalls
- Mocking so much that the test proves nothing.
- Flaky tests that people learn to ignore; fix or delete them.
- Writing tests only at the end of the project.
Start with the riskiest feature and add tests as you touch code.
0