There are certain properties that make a unit test both fit-for-purpose and also a good test. We’ve put together a list below and we’ve tried to keep it as language agnostic as possible in order to make it clear that it applies to your development environment as much as any other.
Properties of a Good Unit Test
- Good tests are automated. We think that if you’re looking to get the most of out of your unit testing regime, the best tests run without any effort and they also provide the pass/fail criteria as an output when they’re done.
- They also have the right level of coverage. There needs to be a thorough approach to finding problems. We know that bugs quite often seem to collect in the same places in the code but you should still be testing all reasonable scenarios regularly.
- Unit tests should be replicable. If your tests don’t produce the same result each and every time – there’s probably something wrong with the test. Make sure there’s no dependency on parameters that aren’t tightly managed.
- There should also be a very high-degree of independence in unit tests. Ideally, they should only test a single behavior at any point in time. The idea is that when a test fails you should be able to tell exactly where the problem is in your code. In addition, a test shouldn’t depend on the result of another test. They must be isolated from each other and run on a “clean slate”.
- It’s a good idea to ensure that your test design follows the high-standards we know you set for your code. When someone scans a test they’re not familiar with, it should be immediately apparent to them exactly what it is a test does. Naming conventions should be adhered to, tests should follow a similar pattern of construction, and they should also be concise as possible so that complexity does not creep in…
- Good unit tests execute quickly. We know that developers don’t enjoy extra work (who does?) so to make running tests regularly attractive – they need to be fast. Ideally no test should take more than a fraction of a second to run, and the whole suite of tests shouldn’t take forever to run. That gives developers an incentive to test frequently and catch problems fast.
- You might also want to consider eliminating any testing of third-part code (it’s their job to test their own DLLs, not yours).