The 2 Golden Rules of Pragmatic Unit Testing

Unit testing is one of the most annoying tasks in every software engineering project. On the other side, it’s also the most efficient way to ensure the quality of your created software. However, there are still many ways to reduce the time you have to spend on your unit tests, but still get the same output. In this article, I’ll show you the 2 most important rules that you should stick to to approach your unit tests in a more pragmatic way:

1Automate as much as possible

The first rule is kind of obvious: The more you automate, the less you have to do yourself. Sounds pragmatic – but how can you automate unit testing? Well you can start with automatically generating test code for your defined unit tests. Modern unit testing tools allow you to use some high-level method to define test cases (e.g. equivalence class partitioning: 2 Methods that help you save 60 % of your effort in Unit Testing) and derive the corresponding code automatically (read more here: Supercharge Your Unit Tests with devmate)

But also executing your unit tests should be automated. I mean most IDEs already allow you to execute targeted test suites with the click of a button. But with nightly builds and continuous integration builds, you can take the next step here. These automated test executions allow you to continuously get feedback on your software quality, without the need to think about actually executing unit tests.

2Structure is king

Most time is in unit testing is spent on understanding the tests you have written. Once a test fails, you have to dig into the code again to localize the defect. Every time your requirements change, you have to understand the implications on the existing unit tests, and adapt them accordingly. Thus, the most pragmatic way to approach this is to structure your unit tests in a way that you can reproduce them as fast as possible, based on their name and the written code.

The good news here: there are some practical patterns that you can apply to apply a good structure to your unit tests

• Use a good naming pattern, that gives as much information as possible about the purpose of the unit test. You can find some examples of good test namings here: 7 Popular Unit Test Naming Conventions
• For structuring the code of your unit tests, you can apply best practices such as the Arrange-Act-Assert pattern (read more about it here: The AAA Test Pattern explained with C# and NUnit)
• With the right tool support (see Supercharge Your Unit Tests with devmate), you can even reuse test inputs across different unit tests

Once you apply these two rules in your projects, you should notice that you start spending way less time on unit testing, and more time on actually implementing functionality of your software.

Image by syarifahbrit on Freepik