Good unit tests help you find errors in your code, and are easy to understand and maintain. Bad unit tests however, destroy the whole purpose of your testing effort. If they take over your test suite, you suddenly don’t understand what’s going on any more. Failing test cases are ignored, because it’s too diffiult to find the error that causes them to fail. Chances are also high that the cause of the failing test case is simply that your requirements have changed, but you did not change your unit tests accordingly. Changing them would simply be too time-intense, because you would first have to figure out where you actually have to change something. So how can you get rid of these bad unit tests? I’ve broken this down to the following 5 bulletpoints for you.
1What is the code unit under test? If you cannot anwer this question, you have most probably identified a bad unit test. If you cannot identify which part of your system is tested by a unit test, how will you ever find out the according bug if the test fails? Actually, the unit under test should already be visible from the test name (see bulletpoint 4). Additionally, if your unit test covers more than one part of your system, you have also identified a bad unit test (that’s btw why it’s called UNIT test ;D). If your test fails, you should automatically know where to look for the cause of the error. If there are several positions in your software you have to look for, this costs unnecessary time, and increases the chanced of you simply ignoring this test failure. So don’t hestiate to have a lot of unit tests, and have each of them cover one specific part of your system – it will help you so much when you execute your tests, and just have to go through the results to know where to look for remaining errors in your code!
2Do repeated test executions yield the same result? If you execute a good unit test 10 times in a row (for the same version of the code unit), it will always give you the same result (either fail 10 times, or pass 10 times). If this is not the case, how do you plan to reproduce your test failure? Just executing the unit test again in debug mode will not work, as it might suddenly pass in this new test run. So if your test suits yields different results from one execution to antoher, although the code has not changed, you should do a dig for bad unit tests!
3How long do you need to understand the code/adapt something? If you don’t understand what’s going on in your test case, it has no value whatsoever any more! How do you ever want to change the code once your software code changes? How do you want to find a bug if the test fails? Or even know whether the failure is because of a bug, or simply because the test case is outdated? All these issues make a unit test worthless, if ou don’t understand what it’s actually doing, or how you can adapt it.
4Do you understand the test case without reading the code? The less time you need to understand where to look for potential errors if your test fails, the higher the value. In the end, you want to get this information from looking at your test suite results. If you have to first dig into the test code before you can actually start debugging your software, you found a bad unit test! Actually, what a test case does should be understandeable from its folder, class, and method name. Use a consistent naming pattern throughout all your test cases to ensure this!
5Why is this test case relevant, compared to all others? If you know the unique value (code path) that is tested through a particular unit test, you know that it actually makes sense to run it. If you don’t, you can delete it? Why keep it if you know that the underlying part is already covered by another test? Sounds obvious, but often overseen in practice! If you want to try these bulletpoints in practice, here are some C# examples of good and bad unit tests: Good Unit Tests VS Bad Unit Tests (with C# and NUnit Examples) What do you think of this list? Do you have something to add? Let me know in the comments section below!
When you visit any web site, it may store or retrieve information on your browser, mostly in the form of cookies. Control your personal Cookie Services here.