This is part 5 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 3,
A Spotlight on ABAP Unit Part 4. </p>So you have learned now quite a lot about ABAP Unit: How and why to implement simple tests, what the ABAP Unit Result Display looks like, and some basics about the background of Unit Tests. But you might still oppose the idea that you as a developer should write unit tests. As this reservation towards Unit Testing might be pretty strong I would like to consider some of the main arguments against the proposal that developers benefit from using ABAP Unit extensively. </p>
Still No Time for Testing?
Though this is all quite impressive, you may feel convinced that you have still no time for testing. The answer to this is quite obvious: First of all, you write fragmented tests even without ABAP Unit. So why not systemize these tests with ABAP Unit?
Secondly and more importantly: Writing ABAP Unit test may cost you some more time. But in the long run, writing no tests will be quite more time consuming for you, because you will spend considerably more time looking for bugs.
It´s Not a True Developer's Job to Test?
You may believe that writing tests is a useful thing. But it is not your affair as a developer. This objection is based on an utterly wrong conception of what unit tests are good for. On the one hand, only white box tests as unit tests can really deliver results that clearly point to very small, delimited portions of code.
No quality manager knows your code well enough to write such white box tests that test your code on such a fine grained level. Writing good unit tests may even help you to get a better understanding of your own program: If it takes you a lot of time to think of a test method for a certain portion of your code, this may give you a hint, that you have no clear, explicit idea what the job of this portion of code is. And this of course, fosters error-prone code.
It might even be a good idea to write the unit tests before implementing the productive code: You can have a clear idea of what a certain part of the code should do and condense it in a test method, while you have still not found a good way to implement this portion of code. So write your test method and by using it find out, if the production code you write later does its job.
Why Spend Time to Write Trivial Unit Tests?
You may think that what you test in unit testing is so trivial that it is not worth the time to devise a unit test for it and write it down: "Of course, if I put 5 into the variable, there will be 5 in it." This objection also misses the point and ignores how many benefits you get for free when using ABAP Unit: Even if all unit tests in a program were as trivial as this example, you still might not be able to survey how all the different trivial parts of the program interact.
After all, every program consists just of a huge number of trivial commands. But many trivial commands may sum up to quite a complex behavior or quite a mess. It all depends on how well the code is controlled by the developer. The very fact that your unit tests offer a complete coverage of the program increases the probability that you may detect unexpected side effects of seemingly correct modifications.
Testing With the Debugger or Running Through Traces is Easier?
You may feel more comfortable with testing in the debugger or running through traces. So you are probably the one who likes repeating things over and over again? Or you have not really grasped by now how much effort ABAP Unit saves you?
Imagine, you will run the same debugging sessions after every modification of your program. A dim prospect indeed. With ABAP Unit, you just press a button and a whole battery of tests is executed over and over again. You get the results presented in a perspicuous way with all the detail analyses of the errors described above.
Why not Focus on Integration Testing?
You may believe that only integration testing is the real testing. If there is good integration testing, unit test is not necessary. This objection gets the relationship of unit testing and integration testing wrong: They cannot substitute each other. If all the errors showed up only in the integration tests, there would be not a lot of time left to fix them, because these tests can only be run in a very late stage of the development.
Moreover, if an integration test fails, you need more fine grained tests, that is: unit test, to locate the source of the error. Of course, there may be errors due to bad integration of different programs that cannot be detected in unit tests. Taking these facts into account, it is a good and effective strategy to reserve the integration test for detecting those errors that cannot be found beforehand in unit tests.
Hopefully Determined to Write ABAP Unit Tests After All?
Taking all the benefits of ABAP Unit testing into account, I hope even the skeptic ones among you agree: A complete test coverage of your program with good unit tests diminishes mistakes in your program without much effort and, above all, the probability that unwanted side effects of modifications are detected. After a while you will run ABAP Unit tests after every modification of a program as regularly as you check the oil after fueling your car.
Of course, no amount of unit tests can guarantee you that your program is error free. You may still have overlooked some far off case for which you have made no provision in your program and your tests. But though no absolute certainty is possible, good unit tests surely enhance the quality of your programs, save your time and money and contribute to a stable development progress.
The more errors are found and removed before integration testing, the smoother and faster the different parts of a component will interact in the component they belong to. So writing Unit tests is not a matter of taste, but an indispensable ingredient in the process of writing high quality software. And above all, don't forget: It is also fun to use ABAP Unit.
