What is still worth asserting
A model will write you a hundred tests that all pass and prove nothing. The ones worth having are the ones you had to think to write.
Ask a model for tests and it will give you coverage: one per function, mirroring the implementation, asserting that the code does what the code does. Those tests pass forever, including after you introduce a bug that changes the behaviour and the intent together, because they were derived from the code rather than from what the code is for.
The tests that earn their maintenance cost are the ones encoding a decision. The boundary conditions you argued about. The bug you already shipped once. The invariant that must hold across a sequence of operations: add, remove, add the same thing again, and the count is still right. Those you have to think to write, and thinking is precisely the part a model cannot do on your behalf because it does not know what you meant.
It is equally worth deciding what not to test. Getters, plumbing, framework behaviour, and anything whose test would need rewriting for a purely internal refactor. A suite of two hundred brittle tests is worse than forty good ones, because people start ignoring the red and then the red means nothing.
You should now be able to
- Distinguish a test of behaviour from a test of implementation
- Decide what not to test, deliberately
Loading…