Dear community, it is February 2025. Actually, I should write 2025 in very large numbers, because half of this decade, the 2020s, will soon be over. It is all the more surprising that I keep meeting ABAP developers who don’t know anything about unit tests.
To dramatize the matter even more, JUnit (support for unit tests for Java) has existed since 1997. For ABAP, ABAP Unit has been around since the mid-2000s. At least I think I read that year somewhere. The popular openSAP course on unit testing was in 2018.
In short: a little time has passed. Time in which I have had positive experiences with unit tests. Below is a compilation of arguments for using unit tests.
The list is not intended to convince those who are uninterested or refuse to use unit tests. It is intended for all those who are curious and want to venture into the topic and see what positive effects they can expect.
Unit Tests…
- help with early testing in development system that a code works as expected, thus making errors recognizable at an early stage.
- encourage developers to refactor because of the security they give.
- allow a class that has just been developed to be viewed from a consumer’s perspective at an early stage.
- are written once and can then be repeated as often as required without any effort.
- can be automated, so that developers are relieved of manual testing efforts.
- accompany a global class, for example, so that a unit is created that is easily recognizable for all developers.
- force a developer, especially when it comes to cleanly isolated unit tests, to develop a testable design (better than no design at all).
- are part of modern documentation.
- can be debugged and thus provide a quick insight into how a class works as an object at runtime.
- support familiarization with complex applications because they illustrate partial aspects.
- help avoid frequent test transports to the quality assurance system.
- support error analysis by recreating error situations in the development system, where they can be corrected immediately.
- allow the developer to think intensively about test configurations and the associated data and states.
- uncover problems early on because, for example, data dictionary development artifacts have changed in an incompatible way.
- can arouse interest in other topics for improving software quality.
- at some point require dealing with mocks and fakes and associated frameworks.
- indicate a certain quality in the respective code base.
- help to save time and therefore money (that sentence had to be said because managers love it).
These topics came to my mind quickly. With a little more time, I’m sure I’ll find a few more aspects. Most of the time, we overlook what is closest to us.
That’s it for today
Michael