Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
Showing results for 
Search instead for 
Did you mean: 
In this blog-post i want to show you some ideas how to automate testing for ABAP transactional applications.

The challenge

ABAP transactional applications contain a lot of stuff, which is difficult to test automatically:

  1. form printing

  2. database updates

When the user interface is highly integrated in the application, a good approach for automated testing is ECATT. If the API is isolated, we can also use ABAP unit.

Form printing

Forms (SAPScript-Forms, Smartforms) contain often some processing and they are part of the result. So we should test them. In the first test-execution a human could check the form. But in the second and in the third test-execution the machine could compare the created spool-jobs with a snapshot of the spool-job approved by a human in the first test-execution. The spool-API gives us with the function-module RSPO_RETURN_SPOOLJOB the possibility to access the generated content. So automate testing can be reduced to a comparison of OTF-data (only for SAPScript-Forms or Smartforms). In the repository you can find a realization of this idea.

Whenever a change is made to the affected forms, we can check them manually in the first approach and create a new snapshot, which is later used as expected result for the automated tests.

A note to Adobe PDF forms
Adobe PDF forms are bit trickier to test. OTF is a text format and is human readable at least a little bit :). PDF is a binary format and is definitely not human readable. Of course we can create a snapshot of PDF-data and compare this snapshot, but the diff wouldn't be very descriptive. So i omit PDF forms in my consideration.

Database updates

To make testing reproducible it's necessary to prepare the database or to erase the changes after the test-execution.
We have to differ between custom code and SAP standard-code. In custom code, database updates affect often just a few isolated database tables. Here it's suitable to prepare the database tables or to use the OpenSQL test-double framework (class cl_osql_replace), if we can do so. One of my favorite tools in this context is the ABAP DB preparator.

In SAP standard-code database updates affect a lot of different tables, which we don't know at all and which stand in relationship to other tables. Preparing the well known database-tables or using the OpenSQL test-double framework for them is not good idea, because this approach creates inconsistencies and broken relationships. Just think of goods-movement documents. If you you are going to replace the table MCHB (batch-stock) by some test-double, you have an inconsistency between the batch stock and the financial valuated stock in table MBEW. The better approach here is to erase the changes for example by canceling the goods-movement document, which was created in the test.


Transactional applications play a important role in ABAP development. I hope i could show some useful tips how to test them and how to create a scaffolding for refactorings.
Labels in this area