26 Feb
2010
26 Feb
'10
9:28 p.m.
On 2/17/10 6:44 PM, Vincent Massol wrote:
On Feb 17, 2010, at 6:31 PM, Marius Dumitru Florea wrote:
The correct way is :
Wait<WebDriver> wait = new WebDriverWait(driver, timeout);
wait.until(new ExpectedCondition<WebElement>()
{
public WebElement apply(WebDriver driver)
{
RenderedWebElement element = (RenderedWebElement)
driver.findElement(locator);
return element.isDisplayed() ? element : null;
}
});
(Your visibilityOfElementLocated method should return
a ExpectedCondition, not a WebElement).
Jerome.
Hi Vincent,
Vincent Massol wrote:
Note that webdriver.get(url) will just wait for onLoad event to be fired so if you have
js code that execute after you might need to wait for elements. Here's how to
implement a wait:
// Wait for up to 15 seconds
Wait<WebDriver> wait = new WebDriverWait(driver, 15);
WebElement element =
wait.until(visibilityOfElementLocated(By.name("foo"));
where that "visibility" method is defined as something like:
public WebElement visibilityOfElementLocated(final By locator) {
return new ExpectedCondition<WebElement>() {
public WebElement apply(WebDriver driver) {
RenderedWebElement element =
(RenderWebElement) driver.findElement(locator);
return element.isDisplayed() ? element : null;
}
}
} Hi,
Yesterday I wanted to add some functional tests for Create page/space actions and I found
that the Selenium version we're using doesn't work on Snow Leopard (my OS) so I
started looking at issues and found that the pb was fixed in Selenium2/WebDriver. Since I
had wanted to explore it for a while I took the time to do a quick exploration...
Selenium2 is the merge of Selenium and WebDriver.
Pros of Selenium2:
* No more JS sandbox. In selenium1 all the selenium API is executed as JS in the browser.
In Selenium2 the browsers are controlled using their native APIs (JNA).
* Faster (as a consequence of the previous point)
* Allows to do stuff such as file uploads, etc since there's no longer the issue of
the JS sandbox
* No need to start a Selenium Proxy. All you need is to start XE and then you can run the
tests as simple JUnit tests.
* The API is much cleaner (this is to be expected with hindsight). See
http://seleniumhq.org/docs/09_webdriver.html
* There's a very fast executing HtmlUnit
driver (not to be used with tests using JS though since it emulates browser JS support and
thus cannot guarantee the result in the real browser)
GWT2.0 uses HtmlUnit by default to run the unit tests and its JS support
is still limited. I can't run most of the RichTextArea tests.
Now Selenium2 also recommends to use the PageObject pattern which IMO is a very good
pattern that we should use. More here:
http://code.google.com/p/selenium/wiki/PageObjects
+1 I like it too. We could have used this pattern with Selenium 1 too (
something like
http://svn.xwiki.org/svnroot/xwiki/enterprise/trunk/distribution-test/wysiw…
).
In order to get a feel of it, I've committed a first test in the sandbox using the
PageObjects pattern:
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/webdriver-ui-tests/
To run the test:
* Start a local XE on port 8080
* Open the project in your IDE and run LoginTest as a JUnit test
Let me know what you think.
My opinion
* We should test it more, on Ajaxy web pages to verify it's stable and working well
enough
* If that works well enough then we could make it our default way of writing functional
UI tests and start migrating existing tests one by one + write new ones in it
I'll try to migrate some of the WYSIWYG Selenium tests to see how it works.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs