search

MarkusBernhardt / robotframework-selenium2library-java

Java port of the Selenium 2 (WebDriver) Python library for Robot Framework
Apache License 2.0
46 stars 48 forks source link

Think about locator caching #37

Closed MarkusBernhardt closed 10 years ago

MarkusBernhardt commented 10 years ago

Could have some nasty side effects. Still doable, but does someone really need that?

Andrei-Straut commented 10 years ago

When you say locator caching, are you actually referring to the WebElements defined by locators, or are you actually referring to the locators themselves?

If you are referring to the WebElements, what would/could be the side effects of caching, other than possibly StaleElementException or ElementNotFoundException, which are both avoidable with a re-scan?

MarkusBernhardt commented 10 years ago

I thought about caching the found WebElements for a given locator.

You are right, the most common problem would be a StaleElementException. I could then simply reevaluate the locator and done. A more nasty problem is, when someone changes the WebElement dynamically. Let's consider you are selecting the last row of a table and somehow an additional row is added to that table. Then we have a still existing WebElement in cache, but it's the wrong one and there is no chance to realize that without reevaluating the locator.

That said, it would be surely possible to add that functionality. I planned to add the following keywords.

Enable Automatic Locator Caching Disable Automatic Locator Caching Add Element To Locator Cache Remove Element From Locator Cache Remove All Elements From Locator Cache

That would be very easy to implement, but no one seemed to need it.

If you are interested, I could add it.

Andrei-Straut commented 10 years ago

I have not had the time to prepare a test and run this, but if someone changes the WebElement dynamically, wouldn't (or better, shouldn't) it still throw an exception? Besides, in this particular case, I believe the responsibility lies with the user to check whether their locator still actually points to the last element in table (as the user should be perfectly aware that at some point during the test, a new row will be added).

I was actually thinking about implementing this myself at some point when I had some speed issues (see ticket #34 ), but as I could solve it differently, there was no need. Now I still don't really need this, but I can imagine some users with long tests might benefit from it. I believe this particular feature would suit very well people who are testing single-page applications, and they don't actually navigate to different URLs during test execution (Angular, Backbone and GWT come to mind).

As to your keywords list, I think it's a good starting point, and a great idea.