Clean Unit-Testing, What it takes to make good Unit-Tests

Especially young software developers tend to develop in a chaotic manner. They do not focus on code quality, architecture or reusability. Why? Because they need their mental capabilities to create working code. Juniors often forget to care about unit testing at all. And if they write unit test, they do not consider the quality of the test code either. This article is about this issue and how you can avoid this problem by following some easy rules. 

 

This point should be obvious, but especially beginners tend to favor console output tests over the use of test frameworks and writing unit tests. If you are familiar with the test framework of your choice, it takes the same time and efforts to write your tests and verify if your code is doing what it’s meant to do, then writing console tests. 

 

The F-I-R-S-T rule [1] was created by Robert C. Martin – the clean code guru-  and introduced in his book “Clean Code: A Handbook of Agile Software Craftsmanship”. The acronym defines the requirements a unit test has to satisfy to be considered good quality. 

F – Fast: Unit test have to be fast in execution

I – Independent: Unit test must be independent against each other

R – Repeatable: When you execute a test multiple times the result should not change

S – Self-Validating: No one should have to interpret the result of the test. It should either be positive or negative.

T – Timely: Unit tests should be written before or during the implementation of new features not afterwards. 

 

The AAA-Pattern[2] is nowadays the industry standard for unit test code. It means that you should structure the code in three sections:

A – Arrange: arrange your test data. Initialize and set your variables and parameters.

A – Act: execute your method under test with the arranged data

A – Assert: Assert the expected outcome of your test. 

 

Develop your test code as it is your productive code, use the same standards and have high quality expectations as you would have from other system critical parts of your software. So also apply your coding guidelines to your test code as well. 

 

Good test code generation tools create well-structured test code out of the box. By using such tools, you can focus on the requirements of your test and let the unpleasant work do the generation tool. As a positive byproduct you will save time and money and receive highest quality of test code. 

 

Using a test code generation tool doesn’t give your test cases and tests meaningful names. In fact, every code you write is read multiple times but is only written once and edited only a fraction of the times it is read. So meaningful names which describes what is going on and what intention you had is most important. This is something a software engineer has to do manually. No code generation tool can do it automatically.

 

Last but not least it is most important that you include your tests in the review process. Your teammates should review your code as well as your test code and give you feedback if there is something misleading or wrong. Good test code generation tools support with that issue because they often provide an UI and are therefore easier to understand. The test code on the other side is less important because it was generated and therefor considers design patterns and coding guidelines. 

 

You should treat test code and unit tests as part of your software solution and therefor manage it like every other code. If you are using the right tools and have a quality mindset, writing tests becomes a habit and the quality of your code as well as your solution quality increases.