we are trying to establish a testing scenario for our NJX Application,
and took the advice regarding the testtoolids as stable identifiers.
This works fine, and we successfully created some Testcases with WebDriver and Selenium IDE.
Nevertheless we still have some difficulties with the structure of the page itself.
Since there are up to 3 iframes with the DOM of a whole page,
and only a style attribute to differentiate them from each other at runtime
(since we don’t necessarily know which iframe becomes active next we can’t use the ID).
With the Webdriver the problem could be solved with
Driver.SwitchTo().DefaultContent(),
and reselecting the next frame
By.xpath(“//iframe[not(contains(@style,‘display: none’))]”)
The problem here is, that sometimes, even when the playback option is at the lowest setting, the style attribute hasn’t changed yet, and the wrong iframe is selected.
Is there a established/recommended way to handle this problem?
The second issue comes from the fact, that we still have many “old” programs with masks.
Here the testtoolids are generated, and we don’t know if we can rely on the unchanging nature of this ids
How can we handle this problem (if there is one)?
regarding the iframes: Are these iframes in NJX workplace applications?
If yes:
The iframes in a workplace applications also have data-testtoolid attributes. If you for instance start a workplace application and the name of the active page layout is “mypage.xml” then you will see the following data-testtoolid:
Regarding the “old” programs with masks:
The generated testtoolids are different to the testtoolids in njx pages. In njx pages you can move for instance a FIELD control to a different position within the layout and the testtoolid will stay stable.
In the html for the masks the generated testtoolid does just use the row/col coordinates for input and output fields.
Examples: input_9_4
If you move this field to a different position in your mask it will get a different testtoolid. This means: If your masks don’t change or very very rarely change these testtolids might be an option.
There is an iframe with the attribute <iframe … src=“mypage.html”> … the loaded page …,
but at a lower level in the dom.
What i am talking about are the iframes at the topmost level, they have the ids WA0/WA1/WA2 an are being added while browsing from one page to another.
searching for the one with display: block, works most of the time, but sometimes it doesn’t.
if the frames aren’t modified yet because the page loads slowly, you stay in the old frame.
Normally you could “wait” till an element is visible or present in the dom,
but in this case there is always a frame with this style attribute.
And sadly it isnt always the last frame you would have to find. sometimes there are 3 frames present and WA0 or WA1 are active.
It is ofc absolutly possible to find a workaround, like adding a default “pause 5-10 secs” before selecting anything, and maybe there even is a way to ignore these iframes (that would be wonderful), but atm i am mostly on a search for a more elegant/standardised/stable solution. if there is none, we would have to deal with that too.
For production environments we set the default framebuffersize=“3”. Sometimes it is also set higher. But for test environments we set the framebuffersize=“1”. The impact is: You only have WA0. Not WA1, WA2.
Does this help in your test scenario?
If not, could you please explain a little bit more detailed what are your test steps? Thanks.
