ABAP Unit - Introduction
Today is about a somewhat longer introduction to the topic of unit tests and ABAP Units and what you can imagine by them.
What do you actually need unit tests for and are the usual tests that are carried out after development not enough? You can already guess the answer and we will go into more detail on the subject of testing in the following article.
For the developer, testing is just as much a part of it as writing the actual source code. At the time of writing, the developer does the first tests in his head and tries out the logic that he has typed into the editor on the keyboard. For many older ABAP developers, testing consists of checking the finished report in the test environment to see whether the result is correct and the functions behave correctly.
But a lot has happened in the last few decades and the way we generate source code has changed significantly. SAP has also started to think about how to test most of the source code without having to plan extra resources and systems.
Today, unit tests are among the best practices in development and form the basic construction kit for stable and clean development. For this purpose, SAP provides ABAP Unit, a framework for automatically testing the source code in the system.
You will learn the basic structure of a unit test very quickly, but it will take you a while to fully master the tests. Therefore we will introduce you to the basics of the topic at the beginning and towards the end, we will become more and more complex and show you the depths of test development.
In which area are unit tests used that the following graphic should illustrate:
Unit tests are the first tests a developer should perform. They cover the entire breadth of coding, testing as much as possible in the process. The runtime should be short and the tests can be carried out fully automatically.
The picture also shows component tests and system tests. These usually require more effort, resources and runtime. However, we are excluding these tests from our consideration at this point, as we want to focus entirely on the fully automated unit tests.
So what about the scope of the tests? There are enough anecdotes from the Internet, when at the end of a development the test code has more lines than the actual productive code. But this is not a problem either, since the test code has no effect in production and is usually not transported or executed either. On the other hand, it also covers a large number of test cases.
The tests should primarily focus on the public interfaces of an application. Basically that means for you:
- Public methods of classes
- Function modules
- Form routines
You haven't misread, we can also test and validate such objects with ABAP Unit. The full scope of the framework is not available, but the important components should be testable with it.
Hint: If a class is too complex or large, it is also possible to test the private and protected components. We will go into these possibilities in later articles.
There are many advantages to writing tests, which we would like to briefly list and explain some of them in more detail:
- Fast execution of all tests
- Little maintenance
- Stable tests
- Safety net for further development
- Presentation of the requirements
- Documentation of object use
- Avoid repetitive errors
The last two points can be quite important. How do you use the developed class and why were the methods and interfaces designed that way? Unit tests can serve as a kind of documentation, as they can cover precisely such cases and show other developers how the object can be used effectively.
Avoiding repetitive errors is also a good keyword, which we want to explain in more detail. Imagine that you develop an interface and bring it to production after a long test phase. Despite the many tests by IT and the specialist department, an error becomes apparent after a certain time, which you can also fix after a detailed analysis. Six months later, this interface is to be expanded with a few new functions and after going live, the first error reappears, as the same error situation has arisen due to the extensions made. Such errors can then become embarrassing very quickly and can be avoided by unit testing.
The disadvantages are quite clear at this point and consist of only two points:
- Use of test data
- Effort to create the tests
Many developers, maybe you too, are initially deterred by the effort involved in creating the tests. Why should you develop different tests for each piece of source code? The work that you invest at the beginning may pay off for you later in maintenance and further development.
Working with test data is the other disadvantage, because we usually don't have proper data in the development system to run real tests. So we use dummy data or simply too little data to test our logic.
The topic of unit tests is now an established standard and shouldn't put you off using it yourself. The benefits outweigh the disadvantages and there is much for you to learn to master writing tests.