Since you read past the headline I´m guessing you would like to know more about how SAP GUI test automation with Java could work. Well, first of all, there are plenty of tools who use record and replay for this kind of task. However, in this blog post we will take a look at a programmatical approach. To demonstrate this I will give you a short introduction of a framework we are currently developing at NovaTec. The framework is called SAPTester and is bases on the experience we gained developing testIT WebTester.

For web applications, the focus of WebTester, the Page Object Pattern is the de-facto best practice for effective test automation. Since SAP rich clients don´t consist of pages, we had to adapt the pattern. So the Dialog Object Pattern was born.

The Architecture of SAPTester

SAPTester architecture

SAPTester architecture

As you can see, the tests are using dialog objects to communicate through the framework with the SAP user interface. The framework uses a 3rd party driver to interact with the SAP GUI. It also provides a type-safe API: each GUI element type is represented as its own class. These classes provide only functionality specific to their purpose. For Example a SapButton class contains functions like click() and doubleClick() not functions like setText(...).

Code example and explanation

Let’s look at some code. First of all, there is the @RootDialog annotation. It identifies this class as an entry point. This is necessary, since the driver needs the information which window is standalone and which is a sub-window. Every standalone window-class has to have this annotation.

Next there is the @IdentifyUsing annotation in line 2 which identifies the path of the root window.

Further more there a several elements like SapTextField and SapButton which represents elements of the UI and are also identified via the @IdentifyUsing annotation. SapTextField and SapButton are just examples for the usable elements, there are many more. There is also the possibility to create your own custom elements if necessary.

In rich client context there are two kinds of navigation use-cases:

  1. Changing the content of the current window
  2. Opening an additional window like a popup

To model this in the DialogObject you have to make that distinction as well. In case a new window is opened you have to add the @SubDialog annotation to the method in order to instruct the framework to switch its context. Otherwise you can use plain navigations methods (cf. PageObject pattern).

Conclusion

This framework is still in development and we are adding new features frequently.

Also currently there is a third party software mandatory which requires a licence. The Framework itself will be free to use.

In the not so distant future we plan to release the first 1.0.0 version, so stay tuned, and follow us on Twitter (@NT_AQE) for constant updates not only to this framework, but also for more information about testing.

Leave a Comment

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close