This is part 3 of a weblog series on ABAP Unit. If you are interested, you find the other weblogs of the series here: A Spotlight on ABAP Unit Part 1, A Spotlight on ABAP Unit Part 2, A Spotlight on ABAP Unit Part 4, A Spotlight on ABAP Unit Part 5.
After you have seen how to implement simple ABAP Unit tests, let us now consider some concepts behind this tool.
Unit Tests versus Integration Tests
In contrast to functional or integration testing, the portion of code tested in a unit test is quite small, and it is tested during the implementation phase and not after the implementation is finished. A unit for unit testing is the smallest portion of a program, a class or function module which can be tested in isolation.
This means that the portion of code to be tested does not depend on any other portion of code and has an effect that can be verified: For instance, it moves a data field to the shared memory, it parses a string and writes the first three letters to a container, or adds an address to a database table.
Why Testing Small, Isolated Units?
At first sight, you might consider it to be quite trivial and useless to test such things. But testing small portions of code that have a perspicuous function has many advantages:
- It is easy to locate the problem if anything goes wrong. The area where the error can be hidden is minimal.
- A mistake in one test cannot cause other mistakes in other tests of the program because of the isolation requirement.
- You need less effort and brain to construct a simple test than to create a complex test scenario.
Another major advantage of unit tests stems from the fact that unit tests are written during implementation. When running out of time during implementation, you as a developer are strongly inclined to shorten or even cancel the test phase, if it is scheduled after the implementation phase. When testing is a regular part of implementation, things are different. Testing cannot be postponed or cancelled.
Systematic versus Ad Hoc Testing
In fact, developers who do not use unit tests tend to write small tests every now and then when writing production code. They create simple test cases and use the debugger or study traces. This way, a unit test is just a systematic extension of what you as a developer are used to anyway. Now using ABAP Unit, you write a lot of small unit tests in a structured way. Once they are written, the whole bunch of tests can be repeated time and again without further effort every time you start the automatic test execution of your unit test task.
During the pre-ABAP-Unit phase, you spend a lot of time working your way through the debugger, look for the line you need in tiring and never ending traces and, above all, your test coding is ad hoc, fragmentary and may get lost as soon as you have written it. With ABAP Unit things are completely different: No test case gets lost, the lines you are testing are in the focus of your attention after the test, and no fighting through the code is necessary. Viewed from this perspective, ABAP Unit is a tool which helps you to focus, store, and organize the tests you would have written anyway in a less structured way, and to run them after every modification of your code by just pressing one button.
Complete Test Coverage
What is important about unit testing is that you accomplish a complete unit test coverage of the program you test. What makes unit tests so mighty is the fact that with complete unit test coverage, you can detect side effects of modification as in our example. You change part A of your coding. The change seems to be successful, because the part you changed behaves the way you expected. But not intended and unforeseen by you, your modification of part A has an impact on another part B of the program which does no longer work properly now.
ABAP Unit Tests as Part of the Production Code
Unit tests are written as part of the production code of the program they test. This avoids a lot of problems which arise when test code is separated from the production code:
- You need to keep subsequent versions of the program in sync with test code.
- You must make sure that your test code is transported with the production code.
- The test code allows only black box test from an outside perspective on the production code.
Since Unit tests are part of the production program they test, it is easy to take account of every change in the production code being reflected by a change in the test code, if it is necessary. Your production and your test code are always in sync without greater effort.
ABAP Unit Tests Not Compiled on the Production System
Wherever your program goes, the test code automatically follows. And last, but not least, in a production system the test code does not increase the program load: The compiler does not compile the test code in a production system. So there never is any test code on the stack in a production system. The fact that the test code is not compiled in a production system has one important consequence: Though test code can and must reference production code (how else could it test the production code), production code must never reference test code. Otherwise in a production environment when the test code has vanished, you would end up having empty references.
Finding the Right Test Data - an Important Task
Regarding the last more comprehensive test example, you might still feel that one reason why the ABAP Unit test was successful in the first place went uncommented so far: It was only because we had test data sets with the same price that in our unit test the additional flight could not be added to the internal table.
First, I admit that the example only worked so well because of the cleverly devised test data. But let us be honest, which examples or demo can do their job without some fiddling?
But what is more important than this:
The test data is a crucial aspect of every test, whether it is a unit test or an integration test. You should spend some time on finding good test data, which covers not only the bread-and-butter cases, but also some exotic cases which might happen every now and then.
With ABAP Unit it really pays to invest in searching good test data, because you can use the same test data time and again with the push of one button. In the next weblog I will tell you in some detail what exactly happens after you have pushed the button and run the test. |
