Webdriver (ChromeDriver) with Play?

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 ide开发者_Python百科as to fix this? Thanks.

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.