Keep your code clean with ABAP Unit Test Framework in Eclipse

Keep your code clean with ABAP Unit Test framework in Eclipse – THEORETICAL INTRODUCTION

Have you ever thought of how important is testing in our life? For instance, imagine we build a car and fit together all the pieces without even testing a single part of it. Then, when the construction is finished, we enroll in a car race, expecting it to function as designed. Do you think the engine will even start? I think we have reason to doubt it.

Therefore, what can be more satisfying than testing our products and fixing the errors to ensure the delivered quality to the customers? In the field of software development this activity is known as the so-called error analysis.

The today’s article is the first from a two part series which focuses on leveraging the ABAP Unit framework in Eclipse. This first theoretical part offers you the necessary know-how for  building Unit Test Cases for the source code using a practical example. In the second part we will demonstrate the exact procedure based on a practical example.

But first…

Why test an application?

A project lifecycle involves many procedures and stages to be followed in a methodical way. As software developers, we should be aware, that there is always the need of testing a product during the development and integration phases of an application. Our goal for it is to last for a long period of time and to perform resourcefully.

Testing is essential and offers several advantages:

  • less defects leading to the improvement of overall capacity and accuracy
  • it is more cost effective related to future developments
  • improves the quality and ensures the application performance
  • encourages customer’s satisfaction and confidence
  • keeps your position in the business field competition

Computer systems are often complex and hard to understand. As a result, various methodologies have been implemented to evaluate the behaviour of a product. In the light of testing our software code, there are several testing practices used along the lifecycle of an application, as presented below:Testing practices development

Figure 1: Testing practices used along the lifecycle of an application

1.Unit Testing

It is the first level of software testing where individual units of code are tested to see if they work as expected. Consequently, each piece of code is subjected to a series of test cases. It can be performed manually, but usually tests are automated.

2.Integrated/Component Testing

It is a technique focused to test the integration of different modules that were previously unit tested by grouping them in multiple ways and to check their behaviour and data communication. Tests are defined in an integration test plan and applied to these aggregated components.

3.System/UI Testing

It is a testing technique that focuses on the UI (User Interface) design structure. Can be executed manually or by using automated tools. It is a practice used to confirm the properties and acknowledge the state of the UI elements. This can be effectively achieved by creating a diversity and combination of test cases.

4.Exploratory/Acceptance Testing

It unscripts the Quality Assurance (QA) technique used to investigate and discover what works and what does not work in an application. Testers have the possibility to explore, learn and check the application in real-time. Test cases are not necessary beforehand, usually testers decide on the fly what to test next and how much time to spend on a particular functionality.

Except for the Unit Testing technique, when testing an application the inside details of it are seen as a „black box” for the tester. Nonetheless, as prerequisites there should exist a basic understanding of the system design.

Automated Testing versus Manual Testing

First and foremost, what is automated testing and how can we define the manual testing?

Automated testing is a process of testing the software code by running a minimum set of scripted tests. These tests are executed using an automated tool that will eventually report the actual values and compare the results with the expected outcome. The aim of the automated testing is to minimize as much as possible the effort and the time consumed. This technique is appropriate and convenient for large projects, particularly if they are too complex to rely only on manual testing.

Manual testing , on the other hand, is a technique of finding errors and defects in a software application by performing a suite of test cases by a human. It is not necessary to have knowledge of an intermediary automated tool, but it may be very time-consuming taking into consideratio, that, to ensure the completeness of testing, testers need to a create a suitable schema that will lead to a detailed set of important test cases to be covered.

It would be ideal in the first place to manually test the code of a new application or after any major change of it and then to create new automated tests for a better coverage and understanding of the implemented functionalities.

Having said that, chances are that there we will be the need to combine automated testing with manual testing in order to provide a complete and fully covered test plan. The reality is, there is no ”better” or ”worse” procedure, they are just different.

What is Unit Testing and when should we use it?

Let us start by answering the second question. The suitable response would be: everytime we want to test a small unit and its behaviour. You may be wondering what is a unit then?

A ”unit” is defined as the smallest testable component of an application, such as a class or a method, that can be isolated from the rest of the code and controlled to investigate if it fits for use.

As opposed to the other testing techniques, there is a need for a solid understanding of the system architecture when using ABAP Unit Testing. Therefore, Unit Testing is also referred to as a „white” or „gray box” testing and consequently, unit tests should be created and defined by a developer.

Most programming languages have designated unit testing frameworks and so does ABAP. Here, all the background processes required for testing are built into an IDE (Integrated Development Environment), a fact that enables us to execute the unit tests with every compile of the test program.

The most suitable tool in SAP for Unit Testing is the ABAP Unit Framework in Eclipse IDE. This framework is part of the ABAP Development Tools (ADT), therefore, the only thing you need to do is to install the add-on into your Eclipse platform. For those who do not have it installed, yet, you can find more information along with a step-by-step tutorial on this blog article.

Unit tests do not interact with the environment or with external systems of the codebase. They are always running in a simulated and isolated environment, in most of the cases, as a separated program in which unit tests are defined as test methods in local test classes. Thus, when the application changes in the real, productive environment, the unit part will not be automatically informed due to isolation from the system.

In order to make your tests effective, you need to structure the code in a way that makes it easy to unit test. Nevertheless, it requires a bit of practice to get good at it and to understand what to test in isolation.

Unit testing should be applied where tests have a clear meaning. The Business Layer code is commonly suitable for running tests and, hence, it represents the main area where unit testing is focused.

Our goal is to write efficient automated tests alongside with testable code. For instance, when running unit tests we have the flexibility to change the source code and to adjust it to fix the errors and to make it testable. Above all, the most obvious benefit is knowing down the road that when a change is made no other individual units of code are affected.

writing efficient automated tests

Figure 2: Writing efficient automated tests

Advantages and benefits

Naturally, as the first level of performing test cases in an application, unit testing provide some notable advantages. Not only that, when having a proper setup, unit tests are:

  • Fast – typically can be run thousands of tests/second
  • Simple – unit tests focus on small parts of the application
  • Timely – tests are written alternatively with the product code

But also, Unit Tests are very effective because they provide:

  • Major code coverage – in many cases up to 80-90% code coverage
  • Easy error analysis – unit tests point exactly to the place where the code goes wrong
  • Stability – unit test repeatability result in a constant behaviour, fact which makes them stable.

Creating a Test Class

In the SAP field, unit tests have been introduced as part of the Object-Oriented design. On that consideration, we can intuitively notice that unit tests work perfectly with classes. In a scenario where we are not able to test all of the report flow, we should at least try to unit test small parts of it.

Moreover, we should only test the public interface of an application and not the private parts. Normally, we are not allowed to test directly blocks of a report, as INITIALIZATION or START-OF-SELECTION, but we can implement the same logic by converting these into object methods and test them afterwards. Worth to notice here is that modularization is very important for a better programming.

The idea is that we define and implement test classes in the same way we define a regular ABAP Objects class. However, what makes a difference is the  ”FOR TESTING” statement we have to add to the test class definition. Keep in mind that this addition basically separates the application into two different parts: the test code and the production code.

Even though there is not a standard naming convention yet official, SAP suggests us to add a prefix to the test classes names as in ”LTC_<class_name>”, in order to emphasize that they are local test classes and to distinguish their focus. Moreover, what we also need to specify for a test class are the two class attributes, RISK LEVEL and DURATION, used by the ABAP Unit runner to interpret the properties of that class.

The RISK LEVEL attribute is referring to the side effects that could impact the system:

  • HARMLESS – no existing process will be affected by the unit test
  • DANGEROUS – the unit test could make changes to a database or persistent data
  • CRITICAL – both customization and persistent data could be modified

Kindly keep in mind that every unit test should be defined with the scope of being ”harmless”, hence not to modify the environment in any way.

The DURATION attribute is referring to the expected execution time of the unit tests and it can be:

  • SHORT – less than a minute
  • MEDIUM – less than five minutes
  • LONG – longer than five minutes, relatively one hour

Eventually, these intervals can be customized. Yet, what we need to take into consideration is, that if the execution time exceeds the specified parameter, the ABAP Unit runner will throw an error.

In the end, to give a short illustration, a test class definition should have the following format:


RISK LEVEL Critical|Dangerous|Harmless

      DURATION Short|Medium|Long .



Worth to mention is, that the part of code in an application, that is unit tested, is usually called ”CUT” = Code Under Test.

If you are eager to find more about test classes, I suggest you to read the SAP Press E-book publication ”ABAP Unit: Writing and Executing Unit Tests”, written by James Wood and Joseph Rupert.

That being said, we have now arrived at the point of…

Creating a Test Method

A test method can be implemented exclusively in a test class. As a matter of fact, during a test run, test methods are called as individual tests and that means we will only have one instance of the test class per test method.

Notably here, the method that is going to be tested, actually the unit, is usually referred to as the ”Method Under Test” and it is part of the production code.

Test methods have no parameters but, similar with test classes, they have a ”FOR TESTING” addition at the end of the DEFINITION part. Another key point to remember is that a test method is declared in the PRIVATE SECTION of the class definition to underline that it can only be used in the context of its test class and not in other derived classes, as follows:


      […] .



          test_method1 FOR TESTING.

          test_method2 FOR TESTING.


The only situation where the test methods can be declared in the PROTECTED SECTION is when these methods are part of a superclass and are inherited by another test class.

The IMPLEMENTATION part of a test method should always tell us a story about what is going to be tested and this should also be reflected in the test method name. It usually follows the ”given – when – thenpattern that associates with the initialization, execution and result phases of the test case. We should think of a test method similar to a logical story in the following way:

given -> a particular environment

This is an initialization part where our global class is instantiated.

when -> we execute this CUT (code under test)

Here we normally call the method that is going to be tested together with the specified input values.

then -> this outcome is expected

A test method has one or a few inputs and usually a single output.

Significantly, in the ”then” part of the test method, the outcome is validated through a comparison between the actual value that the method under test is returning and the real expected value. If the results do not match, the Unit test framework will throw an error. This comparison is made using one of the utility methods provided by the ABAP class ”CL_ABAP_UNIT_ASSERT”, which is called ”ASSERT_EQUALS”.

The most often used utility methods alongside with their SAP documentation are:

– ASSERT_EQUALS – ensures equality of two data objects

– ASSERT_BOUND / ASSERT_NOT_BOUND – ensures the validity / invalidity of the reference of a reference variable

– ASSERT_INITIAL / ASSERT_NOT_INITIAL – ensures that data object value is initial / is not initial

– ASSERT_TRUE / ASSERT_FALSE – ensures that a boolean equals ABAP_TRUE / ABAP_FALSE

– ASSERT_SUBRC – ensures a specific value of the return code

– FAIL – report unconditional assertion

– ABORT – abort test execution due to missing context.

They are also known as ”assertion methods” and their ultimate purpose is to pass messages to the ABAP Unit runner.

Naturally, it is not necessary for a test method to follow the above pattern, it is just a style of writing tests that helps for a better understanding of them. Instead, it is mandatory for it to include the logic inside these three parts.

Importantly to know about is that there are several special private methods used in test classes which are provided by the ABAP Unit framework. They implement a unique test behaviour and include the test objects and the connections needed for a proper execution. These are:

  • SETUP( ) – instance method that is executed before each individual test or before each execution of a test method

The ”given” part of the tests can be implemented in the SETUP method, only if the test methods have the same code under test.

  • TEARDOWN( ) – instance method that is executed after each individual test or after each execution of a test method
  • CLASS_SETUP( ) – class method which is executed once before all tests of the class.
  • CLASS_TEARDOWN( ) – class method which is executed once after every test of the class.

Actually, they are also called ”fixture methods” and have predefined names so that the ABAP Unit could recognize them at runtime. These methods are optional and should be used only if we need them.

There are already several software companies that have adopted the Unit Testing technique as part of their development process. Although it may be difficult to get used to it or to figure out what cases to cover, in a long-term perspective, unit tests lead to less maintenance efforts and costs. Unit tests are likely created by the developer, the reason for we call it ”white-box” testing, and it makes sense because the person who wrote the product code is the most qualified to know about what and how can be easily accessed and tested. Additionally, having a lot of tests for the small components of the application will demand much less debugging overall and that will also save our time. And time is very important for a developer, isn’t it?

Now, that you completed the theoretical part, you are ready to practice. Do not miss the second part of this series, which will show you how to build Unit Test Cases for the source code based on a practical example.

Sources of the images:

Andra Atanasoaie Associate
Phone: +49 (0) 7031 714 660 0

Organize your work with abapGit

What is abapGit and how does it work? 

Assuming you are already familiar with ABAP programming but have not heard about abapGit, let us first shortly introduce you to the Git world.  

Git is a version control system, „VCS”, which gives us the possibility to follow changes in a file. Yet, you may be wondering, what is a VCS and what is its purpose? 

A Version Control System, also known as a Revision Control, is a system that gathers and stores the history of changes in any collection of files or source codes during their lifetime cycle. Each change is assigned to a „revision number” and has a bookmark that includes when and who made that specific change.  

Versioning procedures have become more and more necessary in the field of computer science. Significantly, a version control system allows us to go back to or restore an older version, in case there is an undesirable change in or deletion of a software program. 

ABAP itself also brings in a version control system, but this system is closed in its own environment, hence it does not allow working together with “outsiders”. This happens particularly for opensource projects, but also in general, for all source codes, and for that reason, sharing is quite complicate. 

If you are interested to learn more about Git, we highly recommend you the book “Pro Git” written by Scott Chacon and Ben Straub. It is available under 

In the landscape of SAP development, abapGit comes as the Git client written in ABAP. It is an Open Source project initiated by Lars Hvam under an MIT License. You can find his blog posts on 

More helpful information about abapGit itself and other great ABAP open source projects can be found in the great blog of Graham Robinson, which is also the basis for the article today: 

In this article we will focus on the installation and utilization of the ABAP Git using GitHub and AWS CodeCommit. In the following procedures, the environment used was SAP NetWeaver 7.5. Now let’s take off on our journey. 

Four steps away from the abapGit experience 

In order to be well equipped to explore the abapGit features, further are the steps needed for setting up and connecting to the development platform and hosting services. 

Step 1: abapGit Server installation 

First and foremost, all we need to do is to run the abapGit project on our ABAP development system. 

Considering you already have access to an SAP NetWeaver installation, open the SAP GUI client and create an ABAP Report “ZABAPGIT” via SE38 or SE80 transactions. Then replicate the code from this link:  

Activate and execute your report. Consequently, the abapGit Homepage will be displayed on screen.  


Please keep in mind that if you want to update your abapGit project to a newer version, you just need to replace the code in the report with the most recent settings and the upgrade is done. 

In other words, this is a straightforward manner through which you can download the most recent version of the abapGit whensoever. Easy, right? 

Step 2: GitHub Root Certificates download 

In this next step, we will carry on with the SSL setup which allows us to use the online feature of the Git server. As opposed to, offline projects operate behind firewalls and without SSL. An SSL, “Secure Sockets Layer”, certificate is a text file with encrypted data that we need to install on our server for establishing a secure, reliable and responsive communication with a web browser.  

Nowadays, the most popular web-based community hosted by Git is GitHub. To enable the communication between the abapGit and GitHub, it is necessary to install some root certificates on your ABAP system. We have several options for downloading the files depending on the web browser we use, otherwise, we can download them manually. The purpose of these root certificates is to assure the integrity and privacy of the communication data between the server and the web browser. 

We have used Google Chrome as the main web browser. Proceed with the following steps to find the necessary certificates:  

  • Go to 
  • Click on the locker icon near the address bar and then select “Certificate”. 
  • Go to the “Details” tab and click on “Copy to file…” to export the certificate to a .CER file. 
  • Specify the name of the file, choose the path to which the file will be saved and press “Finish”. 
  • Select the “Certification Path” tab and repeat the two previous steps starting from the parent node of the tree until the root node. 

If you want to manually download the root certificates, navigate to the GitHub platform and find the certificates that it is using, as shown for the above browser. Download these certificates from by accessing the “Root Certificates” section. 

You can find more information here: 

We have now the files in the format wanted and, consequently, we can establish the connection with the SAP system. 

Step 3: SSL Setup using SAP Trust Manager 

For the previously downloaded certificates to be acknowledged, we need to install them in the SAP system using Trust Manager application. Therefore, log on to your SAP GUI system and run the STRUST transaction.  

Make a switch to the “Change” mode and from the top-left objects list, open the “SSL System Client SSL Client (Anonymous)” folder. 


Choose Import certificate” from the bottom-left side of the Certificate” box and insert the file paths of the certification files exported earlier from the web browser. 


Select “Add to Certificate List” for each certification file separately, one by one. As a result, the “Certificate List” box should look as follows: 


Save the changes made. The root certificates are now installed on the SAP development system.  

In order to check if the ABAP tools can communicate with the Git server, it is compelling to test if the connection between them works properly. To give an illustration for that, create an ABAP Report “ZABAPGIT_TEST_SSL” via SE38 or SE80 and copy the code from this link:

Activate and execute your program. If the connection has been successfully established, following output is expected:


However, if the connection is not working properly, consider the fact that you may have to set two profile parameters in the RZ10 transaction (see also SAP Note 510007 – Setting up SSL on Application Server ABAP, step 7).  

For instance, in our system we had to set the following values: 

ssl/ciphersuites = 135:PFS:HIGH::EC_P256:EC_HIGH 


Please keep in mind that you need to restart the application server or at least, in the ICM Monitor, SMICM transaction, to restart the icman process! 

Dive deeper into the subject by going to 

Step 4: Git Repositories connection 

Keep your installed abapGit code up to date with the most recent developments and extend the supported object types by downloading the required plugins. 

Particularly, when abapGit is run for the first time, the abapGit tutorial page will be displayed, as shown in Step 1. On the bottom side of the page, you can find the “abapGit related repositories” section. 



Click on the „install abapGit repo” to start the process. Press „Continue” to download the current version of abapGit into package $ABAPGIT, which in this case is a local package. Choose „Overwrite” to update the „ZABAPGIT” program created previously and activate all the abapGit artifacts. 

In a similar manner, choose „install abapGit repo”, proceed the steps and you will be then ready to experience the abapGit features. 


An important thing to be detailed here is that not only GitHub platform, which is a web-based hosted service for version control, can be used to connect with the abapGit, but there is also the possibility to communicate using the Amazon Web Services. 

We as Inspiricon work a lot with the Amazon Web Services, so for us, it would be the best to use the “AWS Service CodeCommit” as Git-Server for our repositories. If you want this as well, the first thing you might want to do after the installation is to connect to the Amazon Web Services, so you can leverage the online feature of the abapGit platform. 

Amazon Web Services, shortened as “AWS”, offers reliable, scalable and secure cloud computing services, database storage and other functionalities to help in the business processes. For connecting to the AWS Server, you need to follow several steps.  

The first steps are similar to the previous ones presented for connecting to the GitHub server, including the download and upload of the root certificates, as shown in Step 2 and Step 3. Next thing is to create IAM-Users in the AWS. It is important that you create in the IAM-User profile “HTTPS Git credentials for AWS CodeCommit”.  

As privileges you should assign at a minimum the following permissions: 

  • AWSCodeCommitPowerUser AWS Managed Policy 
  • IAMReadOnlyAccess AWS Managed Policy 
  • IAMSelfManageServiceSpecificCredentials AWS Managed Policy 

For more information, you can also go to 

After the initial configuration is made, you can create your own repositories in the AWS CodeCommit Dashboard.  

Online and Offline? 

First and most importantly, the abapGit project can be started in the SAP NetWeaver platform using the transaction “ZABAPGIT”. abapGit comes in with the Online and the Offline features. On the one hand, the offline feature refers to replicating a local ABAP package from your system into the abapGit workspace. On the other hand, the online feature allows us to work with repositories. Hence, what it is a Repository? 

A repository, frequently abbreviated as “repo”, is a location where all the files for a single project are stored. Each project has its own repository and it can be accessed by using a unique HTTPS-Url. We need to connect this repository to an existing ABAP package from our system or to create a new one. 


An increasing number of companies and developers around the world have decided to make a switch and use Git as the main control software. In the landscape of the SAP industry, abapGit comes to the help of developers in the form of an ABAP client written in ABAP which completely benefits from the Git functionalities.  

AbapGit is free, fast and provides a consistent, scalable model. Another big plus is that abapGit automatically pushes changed objects to the remote Git repository, being, in the same time, an environment which facilitates the process of parallel development. It is best suited for code sharing and for tracking changes in the development process. 

Open source projects and code sharing beyond company boundaries are a good way to participate to the open source community, to learn and improve your own skills and find new solutions for different actual problems. Furthermore, all these are supported by Git and abapGIT! 

Do you feel enthusiastic to find out more about the subject? We would be very happy to keep you informed with the updates and to present you many more other interesting topics and projects we are also involved in. Stay in touch! 

Andra Atanasoaie Associate
Phone: +49 (0) 7031 714 660 0
Enhancements in ABAP

ABAP enhancements – this is what’s new in NetWeaver 7.40

Easier, more direct, more intuitive

Hello everybody:

Today, we are going to get very technical yet again by taking a closer look at what’s new in ABAP. It’s not just SAP’s applications and tools that are evolving. SAP has also never stopped working on its very own programming language.

Over the coming weeks and months, we will provide you with regular insights into the language, the new tools, testing capabilities, and most importantly the applications in the field of SAP BW and HANA.

Today, we will start with a number of enhancements that ABAP has seen over the past years. Because these changes depend on the system version you are working with, there is a chance that they may still be very new to some of you, while others have been familiar with them for years. And then there may be those of you who to whom they are not even available yet.

A look back at NetWeaver 7.40

The release of NetWeaver 7.40 brought with it some really interesting news and changes in ABAP that have real potential to impact a developer’s day-to-day work. SAP’s own Horst Keller has published an excellent article on this. You can find it here.

ABAP 7.40 has been around since 2013. Since then, we have seen a number of adjustments in the form of different support packages. And even though it’s already 2017, it’s still “news” for many of our customers or “only now” becoming available because the language is tied to the NetWeaver release they are working with.

By now, we’ve had the pleasure of working with this version and the one after that (ABAP 7.5 is also available) for some of our customers ourselves. Unsurprisingly, there may be developers that have to bring themselves to embracing these new topics because that is not what they are used to and they are sure that there is more than one road to Rome.

Two specific examples of what’s new in ABAP

But let’s dive deeper. Here are some examples of how working with ABAP has changed:

To me, one of the most convenient changes is the INLINE DECLARATION. As with a number of other languages, this type of syntax allows you to declare the required data elements directly in the command.

Here’s one example:

This is what this looked like before 7.4:

Data: WA type line_of_itab.

Loop at itab into wa.



With 7.4:

Loop at itab into DATA(WA).


This not only saves you one line of source code, best of all it also means that implicit typing is taking place. Incidentally, this type of declaration also works for field symbols and other objects.

The “value” operator is yet another example of a useful adjustment SAP has made:

Before 7.4:

DATA itab TYPE t_itab.



wa-col1 = 1.

wa-col2 = 2.

APPEND wa TO itab.

wa-col1 = 3.

wa-col2 = 4.

APPEND wa TO itab.


meth( itab ).


With 7.5:

DATA(itab) = VALUE t_itab(

( col1 = 1 col2 = 2 )

( col1 = 3 col2 = 4 ) ).

meth( VALUE t_itab(

( col1 = 1 col2 = 2 )

( col1 = 3 col2 = 4 ) ) ).

This is yet another change that helps eliminate unnecessary lines and commands and, in my opinion, makes the source code much easier on the eyes.

ABAP makes a lot of things easier

Another example of simplification is the implementation of LHS = RHS, which means that commands such as “Move A to B” are now obsolete. All you need to do now is state that B = A and you’re done. The main advantage of this is that you can also concatenate these assignments and use them in function calls or method calls.

Other changes are notable in that they make the code much easier to read:

result = class=>do_something(EXPORTING p1 = … p2 = … IMPORTING p3 = … p4 = … CHANGING p5 = … p6 = … ).

With this, it feels like ABAP is moving closer to JAVA and other languages that allow us to use more complex parameters when passing method calls in-line. With 7.4, this now also works for exporting parameters and changing parameters (this was previously only possible with importing parameters).

Three new commands for transformations

There are three new commands that I personally like to mainly use in transformations:

DATA(lin) = lines( itab).

DATA(idx) = line_index( itab[ … ] ).

IF line_exists( itab[ … ] ).


These commands make checking tables a lot easier. They return the number of lines, the index of a condition, and the check results. You can then go on to directly use all of these values. Before 7.4, you had to start by executing READ commands to determine these checks and there was no way to concatenate these commands. This forced many developers to use auxiliary variables and other such concoctions which did little to make the code easier to read.

Are you interested in ABAP or looking for an expert in the field? I would love to hear you questions or comments.



Jörg Waldenmayer Lead Consultant
Phone: +49 (0) 7031 714 660 0