Imagine yourself implementing a feature, and after some hard work, you decide to commit and push your changes. A pipeline starts running and fails after a few minutes. A few unit tests have failed… This can be a tense moment because you changed the behavior of a legacy application, and you have no clue in what state the test class(es) are. Understanding the failed unit test(s) and maybe the dependency between them can be a challenge that makes 1 hour of work last an entire day.
I want to help you improve the overall quality of your test classes so they are more straightforward to work with. I created a 12-step test to see how much improvement a test class needs. The idea came from “The Joel Test: 12 Steps to Better Code”. It's a test to rate the quality of a software team. I liked the idea and wanted to apply it to tests. Just as with Joel's test, you don't have to do some exotic calculations with test coverages and whatnot. It's just twelve questions you can answer with Yes or No. You can give a test class one point for every Yes answer. Each test class can have a maximum of 12 points, meaning it's perfect. Anything less than 12 has the potential to become more outstanding.
These questions do not cover all the factors determining whether a test class is a joy to work with. Some questions may not apply to a test class because you don't mock anything. It could be possible to have a great test class that answers no to most questions. But if you can respond yes to most of these, then there is a big chance that your test classes are a joy to work with.