The 3 roles to make unit testing great

One person alone cannot create meaningful unit tests efficiently. The result will be test cases that do not fit to either the requirements or the implementation details of your software product. Or even worse, they are failing to test essential parts of the requirements, or redundantly testing the same thing repeatedly. That is why for the development of great unit tests, there must be three roles involved. Although each role might be occupied by several people in your project, the communication between the people in these roles is essential for creating meaningful unit tests.

In this article, I’ll explain each role to you, so that you can check whether you have to adapt your current unit testing practice to make it great again.

The Requirements Engineer

The main responsibility of the requirements engineer is to come up with a set of well-defined requirements that serve as basis for any unit tests. In the end, the unit test should simply be a formal validation that the requirements are satisfied in the implemented software. That is only possible if we have well-defined requirements before starting to test!

To do so, the requirements engineer is the one who has to constantly nag your customer to spill out the details of what they actually want – and is also very good at finding these things out, and documenting them in a way that it is understandeable for others. If some parts of a requirement are not clear or missing for someone in the project, the requirements engineer is also the one to consult with the customer to fill this void.

The Test Expert

The test expert knows how to create meaningful test cases from the requirements. These test cases are optimized for finding the bugs as efficiently as possible (read more on that here: The key to evaluating your test suite effectiveness). To find these tests, the test expert knows the best methods derive the most meaningful test inputs and assertions from requirements. Creating these tests together with the requirements engineer is usually also a good way to validate requirements. If the requirements are missing some information that is needed to find meaningful test inputs, the requirements engineer can clarify this before it leads to confusion during development.

Also, a test expert should be the one knowing when a project is tested sufficiently. At that point, the cost of adding new unit tests will not outweigh the potentially found bugs any more. Once this state is reached, and all unit tests pass, you have reached a satisfying software quality of your release. However, the responsibilities of the test expert also include choosing regression tests that will be kept after a release to ensure the quality of the developed functinality on the long run.

The test expert is also the one creating the code that is executed when running a unit test suite. However, to meaningfully write these tests, a test experts needs information on (i) the interfaces that he consumes, and (ii) the internal code structure to know about mocking and asserting the right things.

The Developer

The developer can give the test expert this information to actually create code for running unit tests. Thus, without a developer, we won’t ever have meaningful unit tests. The developer is the one who has written the code that should be tested. Thus, the developer should know all the details about interfaces and internal logic. Providing this information to the test expert is usually also a good motivation to start documenting your software – and keeping this documentation up to date, so that the test expert knows how the unit tests need to be adapted after every change.

On top of that, a developer can also help a test expert identify the pain points in a software artefact. As the developer is the one writing the code, he or she usually gets a very good feeling for the complex parts that they are not too fond of changing, as they might contain ugly or very complex code. These are usually the points of your software that should be tested the best – and the test expert know best how to do that!

But why is the developer not creating the unit tests from the specified requirements right away? Well that one’s easy – as a busy developer, you usually have neither the in-depth knowledge to create efficient unit tests, nor the time to do so – that’s where he needs the test expert to jump in with her knowledge.

By combining these three roles, you can create great unit tests for every software project. So – look at your current projects and see whether developers, test experts, and requirements engineers are involved in unit testing. If not, try to demand them in your next project, and see how your unit testing progress improves!

Image by storyset on Freepik