TATs - That's what I call the tests people write when they are writing unit tests for the first time on a real project.
Those tests usually don't last more that a few months before they either get deleted or ignored completely because it takes too much time to maintain them, or no one understands what they are trying to test, or no one understands why they keep failing when the code seems fine, or all of the above combined.
What's the difference between TATs and TTLs (Tests That Last)?
TTLs are:
- Maintainable - Maintaining your production code when you have unit tests should not take much longer than maintaining it if you didn't have tests. for example - Assume a class that has 50 tests and suddenly you decide to change the constructor signature for that class. how long would it take you to make sure all the 50 tests for that class run again (or even compile)?
- Readable - Can you understand the test that somebody else wrote? Do you have to debug it to understand what it's testing? can you tell the intention just by looking at the test name? if it failed, will you know where the problem is?
- Trust-worthy - When you finish writing a feature, how comfortable do you feel just running all the tests and seeing them all pass? Does your test test the right thing? Do you have tests that keep failing but you think it's a normal behavior that they fail? Do you have tests that seem to only pass if run in a specific order? Do you have tests that run other tests?
Take any one of these away and the others crumble as quickly as I do when my wife asks me to take the garbage out. As a bonus I can tell you that you what you have if even one of these is true is a TAT, not a TTL.
Have you ever written TATs? Were you able to make the move to TTL? If not, why?