Skip to Content


This is part 2 of my experiences with writing test scripts for WDA with Selenium (IDE). The first part is here: Test Scripts for WDA with Selenium – Part 1: Reasoning, Background.

A general request: Everything here is my current experience. I am learning as I go. So if you have alternative or better solutions for some of the things, please do not hesitate to comment. I hope to improve the blog as time goes by.

The Application

Our application is based on NetWeaver 7.30. It consists of parts using “classic” WDA and also Floorplan Manager for Web Dynpro ABAP. We are not yet complete on Floorplan Manager, that is work in progress. If you are curious about the application itself, see here: SAP’s internal solution for Forecast Reporting.

The First Script – Load Page and Test if we Arrived

As mentioned is part 1, everything I did so far uses the Selenium IDE. That was the fastest way to get started. To simplify the layout of this blog, I will paste the Selenium commands and parameters as text tables.

So, first step is loading the page – that’s trivial.

open /sap/bc/webdynpro/sap/<pageID>?sap-language=EN

Now we wait until everything is loaded. Already at this point, AJAX strikes. Most of the page content is loaded asynchronously with JavaScript. That’s of course nothing special; Selenium has the “waitFor…” commands for that. See here for details.

In my script, I want to wait until the “Navigation” block is present on the page.


Normally, that is not a big deal. This is the HTML code for the “Navigation” text:

<span class=" lsHdArTitle" id="WD2D-titletext">Navigation</span>

In any normal web application, you would use the ID “WD2D-titletext” to identify the <span> and the use the waitForElementPresent of waitForText in Selenium to wait until it appears on the screen. In normal language, that means that you wait until that <span> with that text “Navigation” appears. It is the safest check.

The problem is: The IDs in WDA are generated and not stable, so I cannot use them and expect the script to run later on. So I cannot do a test for one specific page element with a unique ID. Therefore, I was looking for the next best thing. My approach was to wait for a <span> with the correct text. Using XPath, that is easily possible in Selenium:

waitForElementPresent //span[text()=’Navigation’]

That halts the script until the page has a <span> element with the inner text “Navigation”. On top of that, you could script additional checks, like if it really the only <span> with that text, what its position is etc. But at that point, that was enough for me.

When executing that script a couple of times, I saw that even this did not guarantee that everything was loaded. Further actions sometimes failed. I suspect that there are still JavaScripts being loaded in the background. I could not identify what exactly I must wait for to be sure that everything is loaded 100%. If anyone knows, please let me know!

So I added another short pause:

pause 1000

Not very elegant – but as mentioned, let me know if you know more.

That basically concludes the first script – I just check if the title is right:

assertTitle Page Title

Second Script – Everything There?

The second script merely checks if all expected UI elements are there. I used the same technique with XPath as above. Most is pretty basic.

We have a few tabs:


WDA implements them with <span>, too. For example:

<span class="lsPnstLabelSel" ti="0" tabindex="0" id="WD0140-title">Modules</span>

So same thing as before.

waitForElementPresent //span[text()=’Modules’]

On the same page, we also have the general navigation of the Floorplan Manager:


WDA implements those with normal links, meaning <a>.

<a href="javascript:void(0);" title="Report Configuration" ti="0" tabindex="0"
     class="urLnkChoice urTxtStd urLnkChoiceMnuIco" id="WD021E" lsevents="{}" lsdata="{0:'Report\x20Configuration',1:'Report\x20Configuration',2:true,3:'WD0225',4:'',5:''}"
     Report Configuration

So the XPath is slightly different:

verifyElementPresent //a[text()=’Report Catalogue’]

As before, this simply checks if there is an <a> present on the screen with the inline text “Report Catalogue”.

The next challenge was to check for the individual menu entries that hide behind those menus:


To make it short: I found no realiable way to script the opening of the menu and then a check on the items. So I used a workaround: The script opens the “Map” view of the navigation:

click //span[text()=’Map’]


So now I could check all entries. WDA uses <a> tags again.

verifyElementPresent //a[text()=’New’]


Some advanced XPath madness follows in part 3…

Test Scripts for WDA with Selenium – Part 3: More Advance Stuff With XPath

To report this post you need to login first.

Be the first to leave a comment

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

Leave a Reply