Why is unit testing so popular

Unit tests and the myths surrounding them

Why unit tests?

Testing products before they are shipped is not a novelty. Machines of all types are extensively tested for their stability, runtime and safety before they reach the customer. In the case of physically existing products, physical properties can therefore also be tested. But how can software be tested?

Software technology distinguishes between the most varied of test types. In this blog entry we will limit ourselves to one of the common test types, which are easy to use and maintain with comparatively little effort and thus represent a great development support: unit tests.

In their most primitive form, unit tests are first of all there to check that a software component (a unit) always returns certain expected output parameters from a given set of input parameters. Unit tests are part of the so-called "black box" tests. In these, the internal functioning of the tested component is not understood and checked, and only the output with a defined input is checked.


A major advantage of unit tests is that they exist during the development of the program code and thus help to detect errors in the initial development phases. In these development phases, the software does not have to be fully developed as a whole - individual modules of the software can still be tested in isolation. When the program is adjusted, for example due to change requests from the customer, it can be continuously verified that the functions are working correctly and that no unexpected side effects occur. If several developers work on software, they can constantly verify that their own changes have not had any unexpected (negative) side effects on other software parts.

Especially with larger projects, the additional effort for unit tests is initially seen as inefficient. The effort pays off immensely in the long term, especially in the initial phase of a project. The automated execution of these tests ensures that every further expansion stage of the software is always available without errors.

In general, the following applies: The later an error is found, the more expensive it is to rectify.

Fig. 1: Advantages of unit tests


Problems and reasons against unit tests?

In the following, we provide answers to common problems and supposed reasons that speak against creating unit tests.



Fig. 2: Common problems with and reasons against unit tests


The method is too complicated to test.

If a test fails with a large method, it is all the more difficult to find the cause of the error in the method. If a method is so extensive that it covers several functionalities, these different functionalities should be outsourced to different methods. These methods can then be tested, each individually.

In general, the more complicated the functionality, the more important the unit tests. Unit tests help to understand how the program works and, above all, they support the maintainability of the program.


How is a test supposed to reveal errors in my program code if I write both myself?

A common question when it comes to writing unit tests. Tests generally support the development process by actively considering possible scenarios. One guideline to stick to is that unit tests should be written from the perspective of the user. It is not the implementation that is tested, but the behavior that is required of a function.

Experience has also shown that incorrect entries are tested more frequently in unit tests. Often times when testing manually, thinking about what the desired result is. It is also interesting to see how applications react to unforeseen scenarios, such as when performing an action with nonexistent data.


Preparing the tests is more complicated than what I want to test.

There are several reasons why unit test preparation can be complicated. On the one hand, the creation of the test data can be extensive. In this case, it makes sense to provide test data centrally for all unit tests, since they can be used in further tests. This often happens when writing tests for functions that access data from an external data source.

Another case is that methods to be tested are in classes whose isolated instantiation is difficult for a test.

The consideration of outsourcing the method can make sense here.


I don't have time to write unit tests.

If developers are under time pressure, they often only see the additional effort in unit tests and suppress the actual benefit. In times when the developer has to develop a feature quickly, careless mistakes are made more often. For this reason, unit tests also make sense during these times. The following picture shows the vicious circle in which the developer often gets involved:




Unit tests are an excellent opportunity to test software during development and thus significantly increase quality. By preventing errors in all software modules, it can be ensured that the end result is much less error-prone and much more maintainable. If the tests are co-developed from the start, the additional work involved in writing tests is also reduced, since it is ensured that individual functions of the software can be tested properly and in isolation. Experience shows that developers notice the enormous added value of unit tests after a short time, as they feel more confident about changes or further developments.


Cover picture credits: https://pixabay.com/de/checkliste-umfrage-h%C3%A4ckchen-ok-2320130/