Did you try/hear about Selenide (http://selenide.org/)?
It's pretty simple wrapper, that gives you a "lazy proxy" version of WebElement (SelenideElement), so you don't need to use all these bulky and limiting agility @FindBy-s.
It also gives more "readable" explicit waits of style:
element.shouldHave(text("foo"));
over Selenium's:
wait.until(textToBePresentInElement(element, "foo"));
And it improves original selenium's implicit waits to be more smart:
- wait for visibilitiy (not just existance in DOM) by default,
- wait for "nth element to exist&visible in collection",
- wait for "element satisfying expected condition to exist&visible in collection". (you can configure/disable the correspondent timeout when needed)
With selenide you can almost completely get rid of bulky xpath for complicated locating cases:
$$("#list li").filterBy(cssClass("enabled")).findBy(exactText("foo")).find(".remove").click();
// over
$(By.xpath("//*[@id='list']//li[@class='enabled' and .//text()='foo']//*[@class='remove']")).click();
Here
$$("...") // is the same that driver.findElements(By.cssSelector("..."))
and
$("...") // is the same that driver.findElement(By.cssSelector("..."))
with the difference that returned element objects - are "lazy proxies"
All filter/find methods above - also returns "lazy proxies", giving you agility to remember in varialbe whatever you want...
According to my experiance, the design of Selenide does not cut any Selenium's original functionality, and so does not limit and control the way you build automation.
Hm, honestly speaking, there is only one "cut" at this moment - instead of WebDriver object, you get its "procedural wrapper" in a form of a "bunch of static helpers", which work for 99% of cases, but sometimes one might need to operate on two drivers in one test - and this will be a bit "bulky" with current Selenide. But we have this in Selenide's backlog, and soon we will close this gap and provide an object oriented wrapper over original WebDriver.