Comment by mingusrude
3 years ago
Maintaining tests that only test that things haven't changed can be a nightmare if you actually want things to change (like when you're making a change to the logic of a system). They can also be a real pain to maintain since if they fail you almost never know why they failed, just that they failed. This gives you (or the future maintainer) very little help in figuring out what's going on.
Guidelines for tests that reduce maintenance burden rather than add to it:
* Test the externally visible useful properties of your system, rather than implementation details. Related: don’t bother with mocks unless there’s no other way
* Keep your tests DRY: if there’s some invariant you want to check have it appear once in your test code
* Don’t over-test: you can delete tests and checks that fully overlap with other tests
* If you need to over-test make it easy to regenerate the expected results from your implementation (characterisation tests) as espoused by the article. * the amount of testing effort should be proportional to how important the functionality is. Reduce the effort for low impact features