Webdriver (ChromeDriver) with Play?

2
votes

I'm using ChromeDriver with Play! framework. I have a UnitTest where ChromeDriver is instantiated and make a get request to my Dyndns url. When the test starts, it opens chrome, makes the request but there is no response. It waits indefinitely. And when I closed chrome, testrunner fails with the exception;

A org.openqa.selenium.WebDriverException has been caught, Chrome did not respond to 'NavigateToURL'. Elapsed time was 116077 ms. Request details: ({"command":"NavigateToURL","navigation_count":1,"tab_index":0,"url":"http://myurl.dyndns.org:9000/test/","windex":0}). (WARNING: The server did not provide any stacktrace information) Build info: version: '2.5.0', revision: '13516', time: '2011-08-23 18:29:57' System info: os.name: 'Windows Vista', os.arch: 'x86', os.version: '6.0', java.version: '1.6.0_21' Driver info: driver.version: RemoteWebDriver

When I do not use UnitTest (and TestRunner) and start my test directly with a main method (also initializing the Play! by myself) test runs with no problem. But I need JUnit's assert methods and it's surely better that all tests are run from the same module (I have many other unit and functional tests). Any ideas to fix this? Thanks.

1
junitplayframeworkwebdriverselenium-webdriver

1 Answers

2
votes

What happens is that the http://localhost:9000/@tests fires off a web request to http://localhost:9000/@tests/<your_test_class>.class to run your test class taking up one thread, your test tries to fire off a request to http://localhost:9000/your_path that blocks until the request for http://localhost:9000/@tests/<your_test_class>.class finishes. Thus you wait indefinitely since by default the number of threads is one. So if you increase play.pool > 1, your test suite will work properly.

See conf/application.conf

# Execution pool
# ~~~~~
# Default to 1 thread in DEV mode or (nb processors + 1) threads in PROD mode.
# Try to keep a low as possible. 1 thread will serialize all requests (very useful for        debugging purpose)
# play.pool=3

Note: One thing I found helpful in understanding how @tests work is turning on Network in chrome, then I could easily trace how it works and then it made more sense where the block was.