Integration Tests in ABAP Development und Tool Support

Integration test means testing different software components in a group. A component can be different parts of an application as well as some external systems. With an integration test we assure that those components work together according to the defined interfaces. Before we do integration tests we must ensure that each single component works correctly: this can be achieved by ABAP Unit tests resp. a system test of an external component. A positive integration test is a necessary precondition of a system test of the whole application.

Motivation and Requirements for Integration Tests

If we want to achieve software of high quality we need to test it. In my opinion software should be tested as early and as often as possible. To test with reasonable effort we have to use test tools that allow test automatization. SAP standard offers three powerful test tools: CATT, eCATT and ABAP Unit. ABAP Unit is quite new and can be used to test single software modules – but I don’t think it can be used effectively for integration tests of an ABAP application. The same is true for CATT and eCATT. This will become clear if I explain my requirements for integration tests:

• I want to do automatic and half-automatic test runs.
• The results of test runs should be checked automatically.
• These test cases cover use cases of my application  – not only an ABAP module or a dialog call.
• And last but not least: a test run must use different software components (perhaps even external systems) that work together.

Integration Tests are Difficult 

Integration tests of complex ABAP applications are difficult because of following reasons:

• We have to implement the solution and this means we have to build up test systems. Because usually a single component needs customizing (perhaps even CA-PD Org Management, master data and much more) an integration test usually needs a lot of effort.
• Often external subsystems or other SAP systems are involved. Usually we don’t have all external subsystems (think of the customer’s output management system) during development.
• Test automatization can be complex because we have to test batch processes and dialog applications that trigger batch processes or complex preconditions (think of the execution of batch processes).

So integration tests are a challenge and require lots of effort. This has the effect that integration tests are done often too late. Lets consider as an example the test of a document process:

• A report is submitted (dark processing as well as user interaction is possible). This report generates some output in the correspondence container.
• Then the SAP correspondence tool is called and XSF is generated by SAP SmartForm technology.
• Now we have to emulate following external tools: output management system and an archiver.
• Then a check of the results of the execution is performed: If the results don’t match with predefined data the test  failed.
• Then I can check whether the generated output documents are correctly and linked to the right business object.

This test scenario is an integration test as defined above. We have to do even more and emulate external systems we can’t use during development.

Which Technology should We use for Integration Tests?

I don’t think there is a general answer to that question because it depends on test aspects, the application that has to be tested and so on. I hope we can share our experience with different techniques and discuss strengths as well as limitations. I will present a self written test tool based on a domain specific language and an interpreter as test engine.

Coding Test Cases in a Domain Specific Language 

Let’s consider again the document process mentioned above. When I had to test it I had the following requirements: I needed to emulate several external subsystems and the test cases should be developed by testers as well as customers. 

So we decided to develop a domain specific language (DSL) to code test cases and to write an interpreter for the DSL as test engine. It turned out that creation of test cases could be improved:

• Test case coded  in the DSL can be generated from spreadsheets.
• We can write AddOns to the DSL without doing any modification: The interpreter can be enhanced using BAdI implementations so that we can add new commands.

Let’s Start the Discussion in Munich! 

I don’t think the approach using DSLs is the best choice for every integration test scenario but in the scenario mentioned above it was quite useful.  I was able to emulate an external output management system and to link document processes. Furthermore I could simulate responses of external systems and test difficult error situations.

In this session I want to discuss different technologies for integration tests, share our experience and best practices.