Home/ Questions/Q 6597811
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T18:15:23+00:00

I’m using ChromeDriver with Play! framework. I have a UnitTest where ChromeDriver is instantiated

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    What happens is that the http://localhost:9000/@tests fires off a web request to http://localhost:9000/@tests/<your_test_class&gt;.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&gt;.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.

    • 0