An already implemented (and in use) feature for enhancing Selenium Java WebDriver

[Muhammad Jawad]

Hi,

I have implemented a few wrapper classes that enhance the existing WebElement class such that the StaleElementException becomes irrelevant (it will never happen). This feature is already implemented and being used in a automation tool that I have developed to test a VERY complicated web application, which is web interface of our product (the core product of the company i work for). So this is not just an idea, its already implemented, tried, and tested. 

This feature has been developed such that its usage is optional, it can be used only if a developer chooses to use HtmlWebElement interface (a new interface i added, which serves as a wrapper to the actual web element and contains it) instead of the standard WebElement interface. Therefore, it does not interfere with regular usage of WebDriver and the existing code can work as is.

The high level idea is that the HtmlWebElement "contains" the actual WebElement which is searched either upon first use AND is re-searched when it becomes stale.The HtmlWebElement framework (i.e. the HtmlWebElement interface together with all other relevant classes that support the above mentioned features) also have built in support for establishing a parent child relationship (so allow use of relative xpath locators) and the initialization or stale element refreshing mechanism trickles up till the top level search context (which is essentially the RemoteWebDriver). The framework also supports this for WebElementList.

In addition to auto-refreshing of stale web-elements, this framework also provides several other benefits, such as:

1. Improved performance due to lazy searching (because only those elements of a view/page that are actually interacted with will actually be searched).

2. Ease of handling explicit waits.

3. Ease of handling optional web elements

4. Framework level support for view "windows" and "html-frames".

I know that is just a quick and dirty overview but if any of this sounds interesting or worth pursuing further then do let me know and I will provide a more detailed and organized write up to explain this. In addition, another possibility is that I start this as a separate project on GitHub instead of making this framework part of Selenium Java WebDriver. Just need some advice on how to proceed and how this all sounds.

Thank you.

[Titus Fortner]

Yes, there are numerous open source test libraries built on top of
Selenium that do these kinds of things in various languages (Watir,
Capybara, Selenide, Mineral Oil, Nerodia, etc). This kind of code does
not belong in the Selenium project directly, but I strongly encourage
creating this as a separate open source project. One of the ideas I've
been kicking around forever has been to try to create a roll-up of all
of these projects. I look at a lot of code from a bunch of different
companies these days and everyone ends up implementing the same kinds
of things from scratch, which frustrates my open source inclinations
as wasteful and inefficient. I'd love to be able to get people to work
together to create more robust code that works for more people out of
the box. :)

Let me know when you end up publishing something, I'd love to evaluate it.

Titus

_____________________________
Titus Fortner
Sr. Solution Architect | Sauce Labs
Core Contributor | Selenium & Watir

Austin, TX
(M) 97-TESTER-98 / (978) 378-3798

> --
> You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to selenium-develo...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/9c064fed-166e-4492-a7e1-cc46a1e6067f%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Joshua Bruning]

Agree w/ Titus w.r.t. creating a separate project.

A couple of alternate designs to consider for the stale wrapper piece:

• Consider using java.lang.reflect.Proxy (or some equivalent option, like the bytebuddy library that Selenium uses for org.openqa.selenium.remote.Augmenter). This has the benefit that your library would be resilient to the vast majority of changes that occur in WebDriver/WebElement interfaces (effectively lowering the maintenance cost of the library to 0 for large periods of time). (Note that doing it this way should result in a lot less code, but more complexity - a lot of folks aren't too familiar w/ proxy APIs.)
• Or, implement as an https://w3c.github.io/webdriver/#dfn-intermediary-nodes per spec (well, the behavior change is going to technically violate the spec). Would have the additional benefit of being a cross-language solution (any client could use the alternate proposed relocation behavior by using that WebDriver protocol proxy).

Interested to know what your API looks like for:

4. Framework level support for view "windows" and "html-frames".

I wish stateless alternatives (extensions https://w3c.github.io/webdriver/#extensions-0) existed for locating windows/frames (as the statefulness of those endpoints severely complicates our test procedures for apps that make significant use of them).

> To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.