Scalatest: Support for fluid element search with selenium

Created on 20 Feb 2015  路  8Comments  路  Source: scalatest/scalatest

Currently it's inconvinient to search elements relative to another element. For example, I have a table
val newsHeadlines: XPathQuery = xpath("//*[@id ='gwt-debug-newsHeadlines']//table")

To find nth row inside this table I have to do this:
find(newsHeadlines).map(_.underlying).map(_.findElement(By.xpath("//tr[" + position + "]")))

which seem really long and obscure to me. Is there a better way to do this?
I would be nice if you could chain queries one after another.

Most helpful comment

@NikolajsCmihuns I personally like the idea in issue #517 and shouldn't be hard to implement, i think, I'll talk to @bvenners to decide whether we should include this in the upcoming 3.0.7 or 3.1.0, once that's decided I can submit a PR to the related branch.

All 8 comments

Agree 100%, the API seems flawed in this respect.

find and findAll are methods on WebBrowser, find and findAll should also be available on WebBrowser.Element so you can say something like

find(newsHeadlines).map(_.find(xpath("//tr[" + position + "]"))) 

Its crazy to need to access Element.underlying - you might as well just use raw selenium-java .

Note that you have this in selenium-java:

public interface WebDriver extends SearchContext ...
public interface WebElement extends SearchContext ...
public interface SearchContext {  
    List<WebElement> findElements(By by);
    WebElement findElement(By by);
    ...

So in selenium-java you can just say

d.findElement(xpath("//*[@id='gwtHdlines']//table")).findElement(xpath("//tr[" + position + "]"))

IMO something similar should to be done in the Scala wrappers

(I'm not suggesting that the Option part of def find(...) : Option[Element] stuff is thrown away either, just that find and findAll exist on Element too)

+1 -- I'm working in a fairly complex page, and it would be _much_ easier (and produce much clearer test code) if I could think in terms of navigation within the Elements, rather than globally.

It's also worth noting: I could implement this myself as an implicit class, except that createTypedElement() is private. Is there a reason for that to be private? I mean, yeah, purity, but unless the Scala DSL covers absolutely _everything_ the Selenium does, it seems like it would be useful to make this function available as a workaround.

(Indeed, I'm finding that I can't even successfully copy the relevant code from WebBrowser into my own harness, because Element is sealed...)

Hi @cheeseng , @bvenners . Found this issue since hit on the same problem. Would be good to have ability to do nested element search inside WebBrowser.Element. Could you please look at this and provide necessary functionality. Consider solution proposed by @andyglow.

@NikolajsCmihuns I personally like the idea in issue #517 and shouldn't be hard to implement, i think, I'll talk to @bvenners to decide whether we should include this in the upcoming 3.0.7 or 3.1.0, once that's decided I can submit a PR to the related branch.

@cheeseng I'll reiterate my +1 here. I'd love to see this enhancement in place...

+1 for this
If I was smarter I would try to implement this, but not feeling strong enough.
So can just express my wish that this feature to be added, because at the moment I need to mix ScalaTest Selenium usage-style with regular Selenium usage-style in cases when I need "fluid search".

Was this page helpful?
0 / 5 - 0 ratings

Related issues

lutzh picture lutzh  路  4Comments

curreli picture curreli  路  7Comments

bblfish picture bblfish  路  5Comments

el-dom picture el-dom  路  7Comments

djneades picture djneades  路  5Comments