Skip to Content

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.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Gregor Wolf
    Hi Tobias,

    if I wasn’t already already subscribed to your session on the Community Day I would have done now. Can you already provide more details about the DSL you’ve created? What underlying Language have you used?

    Regards
    Gregor

    (0) 
    1. Tobias Trapp Post author
      Hi Gregor,

      for the business case described above I invented my own DSL. Therefore I identified following domains: outputmanagement (correspondence container, spool, emulation of an output management system…) and document processes (archive link, document management system, …). For each domain I created a domain expert (a special ABAP class) and the test engine class (the DSL interpreter) delegates the commands to the domain expert.

      Perhaps I will add other domain experts like a “BP expert” that can create new Business Partners with certain addresses, roles and BP relations that affect the set of additional receivers of a correspondence. In this case I could use the test tool for a system test for correspondence.

      By the way, I used Object Services as well as OO transactions for implementation. It’s a cool technology that can be used for rapid development. OO transactions can be used to detect “hidden” COMMIT WORK commands but it’s possible to live side by side with classical LUWs. And if you read my blog on SDN you’ll know what kind of language I used for my DSL.

      Dis this answer meet your expectations?

      I’m looking forward to meet you in Munich and I hope that other experts will join this session and that we can share our experiences.

      Regards,
      Tobias

      (0) 

Leave a Reply