Peter Merkač
2013-05-27 09:24:35 UTC
Hi Selenium friends,
With my coworkers we are currently working on a project for automating GUI
tests execution for insurance web applications. Lately we had a lot of
instability problems with our Selenium test automation kit (a.k.a. SeTAK),
which is built on top of Selenium WebDriver. Those Selenium errors were
related to following three areas:
- switching of frames and consequently (NoSuchElementException)
- generally elements were not found (when searching by id, name or xPath)
although they were visible on the web-page
- stale reference exceptions also occurred again with elements visible on
the web-page
Than we came across a solution to retry to execute particular selenium
commands like in the below link
http://stackoverflow.com/questions/4846454/selenium-webdriver-staleelementreferenceexception
While some of the above mentioned errors were corrected as suggested by the
retry solution, a situation, that particular DOM element was NOT present in
the Selenium WebElement tree, although VISIBLE on the web-page of target
web-application, has NOT been tackled. From our experience such situations
were undeterministic, occured randomly and more often on the DOM elements,
which had some JavaScript events e.g "onchange", ... in-behind.
We came to the conclusion that there MUST be some bug in refreshing the
tree of WebElements as maintained by the selenium WebDriver, which points
to actual DOM three of a target web-page. Having this in mind we
implemented a simple but VERY effective solution (tested on our test
environment multiple times), which has been driven by the below
Stackoverflow force DOM refresh without page reload. Our requirement is,
that with DOM refresh no page reload is done.
http://stackoverflow.com/questions/8840580/force-dom-redraw-refresh-on-chrome-mac
to REFRESH DOM tree of a web-page with javascript as suggested in the above
link and than retry to execute web driver commands.
@Override
public void refreshDOM(String elementId) throws WebDriverException {
switchFrame(getActiveFrameId(), 5);
JavascriptExecutor jsExecutor = (JavascriptExecutor) getWebDriver();
jsExecutor.executeScript(buildJQueryScriptDerictive());
jsExecutor.executeScript("$('#" + elementId + "').hide().show();");
}
Of course such DOM refresh has to be used with care in sense of
time-execution impact only when a particular undetermined exception occurs
like in the case below.
public IWebTestResult interpretPredicateWithRetry(IInterpretationContext
interpretationContext)
throws WebDriverException {
try {
interpretAndLogPredicate(interpretationContext, logMessage,
false, 1);
}
catch (NoSuchElementException e1) {
interpretationContext.getPredicateHandler().refreshDOM("UI-MAIN_PANEL");
// Retry to interpret commands
}
catch (StaleElementReferenceException e2) {
interpretationContext.getPredicateHandler().refreshDOM("UI-MAIN_PANEL");
// Retry to interpret commands
}
catch (NullPointerException e3) {
interpretationContext.getPredicateHandler().refreshDOM("UI-MAIN_PANEL");
// Retry to interpret commands
}
catch (TimeoutException e4) {
interpretationContext.getPredicateHandler().refreshDOM("UI-MAIN_PANEL");
// Retry to interpret commands
}
finally {
interpretationContext.setWaitInterpretationHandler(new
DefaultWaitInterpretationHandler());
}
return predicateResult;
}
We are passing in an id of top-parent element, but to fine tune this, an
exact parent element can be found via java-script to decrease performance
impact.
This solution brought a LOT of stability to our selenium gui tests,
therefore we wanted to share it with all of you.
With best regards,
Peter, Toni
With my coworkers we are currently working on a project for automating GUI
tests execution for insurance web applications. Lately we had a lot of
instability problems with our Selenium test automation kit (a.k.a. SeTAK),
which is built on top of Selenium WebDriver. Those Selenium errors were
related to following three areas:
- switching of frames and consequently (NoSuchElementException)
- generally elements were not found (when searching by id, name or xPath)
although they were visible on the web-page
- stale reference exceptions also occurred again with elements visible on
the web-page
Than we came across a solution to retry to execute particular selenium
commands like in the below link
http://stackoverflow.com/questions/4846454/selenium-webdriver-staleelementreferenceexception
While some of the above mentioned errors were corrected as suggested by the
retry solution, a situation, that particular DOM element was NOT present in
the Selenium WebElement tree, although VISIBLE on the web-page of target
web-application, has NOT been tackled. From our experience such situations
were undeterministic, occured randomly and more often on the DOM elements,
which had some JavaScript events e.g "onchange", ... in-behind.
We came to the conclusion that there MUST be some bug in refreshing the
tree of WebElements as maintained by the selenium WebDriver, which points
to actual DOM three of a target web-page. Having this in mind we
implemented a simple but VERY effective solution (tested on our test
environment multiple times), which has been driven by the below
Stackoverflow force DOM refresh without page reload. Our requirement is,
that with DOM refresh no page reload is done.
http://stackoverflow.com/questions/8840580/force-dom-redraw-refresh-on-chrome-mac
From our experience with above described errors we suggest instead of
retrying to interpret selenium commands (or additionally to retry solution)to REFRESH DOM tree of a web-page with javascript as suggested in the above
link and than retry to execute web driver commands.
@Override
public void refreshDOM(String elementId) throws WebDriverException {
switchFrame(getActiveFrameId(), 5);
JavascriptExecutor jsExecutor = (JavascriptExecutor) getWebDriver();
jsExecutor.executeScript(buildJQueryScriptDerictive());
jsExecutor.executeScript("$('#" + elementId + "').hide().show();");
}
Of course such DOM refresh has to be used with care in sense of
time-execution impact only when a particular undetermined exception occurs
like in the case below.
public IWebTestResult interpretPredicateWithRetry(IInterpretationContext
interpretationContext)
throws WebDriverException {
try {
interpretAndLogPredicate(interpretationContext, logMessage,
false, 1);
}
catch (NoSuchElementException e1) {
interpretationContext.getPredicateHandler().refreshDOM("UI-MAIN_PANEL");
// Retry to interpret commands
}
catch (StaleElementReferenceException e2) {
interpretationContext.getPredicateHandler().refreshDOM("UI-MAIN_PANEL");
// Retry to interpret commands
}
catch (NullPointerException e3) {
interpretationContext.getPredicateHandler().refreshDOM("UI-MAIN_PANEL");
// Retry to interpret commands
}
catch (TimeoutException e4) {
interpretationContext.getPredicateHandler().refreshDOM("UI-MAIN_PANEL");
// Retry to interpret commands
}
finally {
interpretationContext.setWaitInterpretationHandler(new
DefaultWaitInterpretationHandler());
}
return predicateResult;
}
We are passing in an id of top-parent element, but to fine tune this, an
exact parent element can be found via java-script to decrease performance
impact.
This solution brought a LOT of stability to our selenium gui tests,
therefore we wanted to share it with all of you.
With best regards,
Peter, Toni
--
You received this message because you are subscribed to the Google Groups "Selenium Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-users+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to selenium-users-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-users/236566e3-8d82-47ba-ab7a-6e7d5b7af3d1%40googlegroups.com?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
You received this message because you are subscribed to the Google Groups "Selenium Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-users+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to selenium-users-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-users/236566e3-8d82-47ba-ab7a-6e7d5b7af3d1%40googlegroups.com?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.