Do You Follow the Ten Standards of High-Quality Unit Testing?

Excellent test suites can make life easier by making people feel safe when changing code; bad test suites are painful and waste a lot of time. There are some rules to well-written, maintainable unit tests that make unit tests higher-quality and more efficient.

1. As Brief As Possible

Because we are testing a single function delivered by a single code unit, it makes sense that the Test should be pretty short. How short the specific need depends on various factors, but it usually doesn't exceed a few lines of code.

2. Do Not Repeat Yourself

Good coding practices apply to test code in the same way they apply to production code. In practice, one of the most accessible rules to break in unit testing is "Don't Repeat Yourself". Some even claim that unit tests should not share any code at all. That's utter nonsense. Of course, we want to keep our tests as readable as possible, but copy-paste is not the solution.

3. Select a Combination Instead of Inheritance

Once you understand the previous two points, you may want to create base classes containing standard code for your tests. If so, please stop now! Such a base class acts like a magnet for all kinds of unrelated shared code and multiplies until it takes over your project, iteration, product. To make sure these don't get eroded by it, be sure to use combination mode!

4. Make It Faster

Unit tests can be run almost always. For this reason, be sure to simulate external dependencies and others that may slow down testing, which is usually a database, external system, or file operation. At the same time, do not do too much. — complete isolation of the tested units is not a good solution.

5. Make It Deterministic

Whenever I hear that someone has 95% of the available test suite and thinks it's good enough to be produced. I always find it ironic because unit testing should ensure 100% workability. Only 100% passing the Test means that everything is normal (for units, you need other types of tests). If your unit test looks unreliable, make sure you find the root cause and fix it as soon as possible.

6. Do Not Label "ignorable" for the Test

Based on the previous points 4 and 5, it must be mentioned that adding "ignorable" annotations to the Test is not a way to fix the test suite but will make the test suite more unreliable because it does not avoid issues like regression bugs.

7. Test Your Test

This point is not about writing tests for your tests but about doing practices like mutation testing, test-driven development, or "changing things randomly" in your codebase frequently to see if any tests fail. You can also do regular brain exercises to identify potential changes to your code that you won't find in your tests.

8. Reasonable Naming Test

Although I don't believe that every project should use some fancy naming conventions for tests, proper naming can judge which part of the code is broken by reading the name of the failed test case.

9. Each Test Contains Only One Logical Assertion

To achieve the wrong goal that can be judged by simply reading the name of the failed test, more than just a good name is needed. A test check must also limit some things. Therefore, a good unit test should contain only one logical assertion that only one output/side effect of the method being tested.

10. Design Your Test

Designing your Test is a meta-trick that covers all the other techniques in this article and those not mentioned here. Treat tests with the same care as you treat/write code. Consider sound design principles and indicators, such as low coupling between test code and production code, code repetition, dead code, etc.

Remember, a good test suite can make you feel safe when changing and refactoring code, making your work easier, while a terrible test suite can make you miserable, waste a lot of time, and make code almost impossible to change.

The above ten standards do not necessarily need to be followed. Teams and individuals can make selective choices according to the actual situation.

--

Author bio

Chen Qi, a senior agile test consultant. As a team member of ZenTao, a well-known domestic project management software in China, he is mainly responsible for the open-source automated test management framework-the development of ZTF. With more than ten years of practical experience in the agile process, he is now committed to the practice and research in test automation and DevOps.