Skip to Content
Technical Articles
Author's profile photo Thomas Weiss

A Spotlight on ABAP Unit Part 5

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 1A 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.


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Nice summary. Yesterday I chatted with a good friend of mine about how all software developers hate long debugging sessions. He is using a logging tool (LOG4J) to avoid this problem and I use unit tests. Perhaps the debugging problem is the best way to introduce somebody to unit testing. Btw I missed the  words Test-First or Test Driven Design in your article. At last here is a nice speech from Kent Beck where he gives some hints how people should start with developer testing:
      Author's profile photo Thomas Weiss
      Thomas Weiss
      Blog Post Author
      Thank you for the interesting information. Of course, topics like Test-First or Test-Driven Design should be a must in every comprehensive theoretical writing on unit testing, and I think it is great that you mentioned it.

      But in part 5 of this weblog series, I want to address and convince those who still do not test at all, not in a sufficient quantity or do not use automatic tests. For this reason I do not want to recommend a total restructuring of the programming style, but to show that incorporating testing in software development does not require a huge change, you have just to organize and enhance the fragmentary testing you do anyway.

      And above all, unit testing is mainstream programming. Test driven design is under discussion, some like it while others are skeptical about it. I do not want to take sides in it. In my weblog I would like to stick to the uncontroversial and widely accepted view on testing.

      Author's profile photo Former Member
      Former Member
      Since ABAP Unit is relatively new, I own lots of coding not covered by Unit tests yet.  I have twice found bugs in parts of my old coding that are easy to test.  The extra 1 day effort of writing a Unit test found several additional bugs in the same coding, so instead of taking one day to fix one bug (and possibly introducing new ones) I needed 3 days to fix 5 bugs.  So Unit tests are useful even far outside the "Test first" approach which I cannot use if I "only" need to change a few lines of old code.
      Author's profile photo B. Meijs
      B. Meijs
      Hello Thomas,

      I have been reading your very interesting blog (much too late) on ABAP Unit Testing. It seems like a very good way of automatically testing your program. However, I'm struggling with the task of setting up valid ABAP Unit Tests, and the problem that I encounter is the fact that the test environment itself (i.e., the contents of several database tables) changes constantly. So how can I define useful expected values for my assertions? What are typical things to test, for example in a report, web dynpro, function group etc.

      I hope you can give me some advice on this.

      Ben Meijs

      Author's profile photo Former Member
      Former Member
      Can ABAP UNIT be used for Interaction Center Web client or Webdynpro ABAP ? If that is the case i can just run the UNIT test to check if the IC application is running fine ..

      Arnab Mitra

      Author's profile photo Abhijeet Kulkarni
      Abhijeet Kulkarni
      It is a useful tool indeed. We have been looking to address the very issue of reducing development effort by have such fine grained testing. ABAP Unit would certainly help us to achieve it. Too bad, we got to know about it so late.
      Author's profile photo Former Member
      Former Member
      Hi Thomas,
        I'm a little hopeful that you may still check on comments on old old articles.

      I'm looking into recommending use of ABAP Unit part or the quality assurance for my customers development process. However I have a question regarding the granularity of ABAP Unit. In articles written by Horst Keller and Andreas Bluementhal - they recommend that when coding ABAP Objects: "Restrict the number of public components. All components that can be declared private should be declared private."

      ABAP Unit seems to be aimed at only testing public components - and to my mind thats not really unit testing - in many cases its more like entire program testing - if I follow Horst Keller's recommendation above.
      The problem I have with this code design approach is that it means that there is a very limited interface available to the ABAP Unit test classes / methods - if I restrict the ABAP Unit to only test the public components of my class - which seems to be the intention of ABAP Unit. I think it is probably possible to get past this limitation with the use of the Friends concept - but this means that we are violating our programming quality rules in order to use ABAP Unit to do real unit tests.