Webdriver (ChromeDriver) 可以玩吗?

发布于 2024-12-03 20:13:37 字数 774 浏览 0 评论 0原文

我在 Play 中使用 ChromeDriver!框架。我有一个 UnitTest,其中实例化了 ChromeDriver 并向我的 Dyndns url 发出 get 请求。当测试开始时,它打开chrome,发出请求但没有响应。它无限期地等待。当我关闭 chrome 时,测试运行程序失败并出现异常;

Chrome 捕获了 org.openqa.selenium.WebDriverException 不响应“NavigateToURL”。经过的时间为 116077 毫秒。要求 细节: ({"command":"NavigateToURL","navigation_count":1,"tab_index":0,"url":"http://myurl.dyndns.org:9000/test/","windex":0}) 。 (警告:服务器未提供任何堆栈跟踪信息)构建 信息:版本:'2.5.0',修订版:'13516',时间:'2011-08-23 18:29:57' 系统信息:os.name:'Windows Vista',os.arch:'x86',os.version: '6.0', java.version: '1.6.0_21' 驱动程序信息: driver.version: 远程网络驱动程序

当我不使用 UnitTest (和 TestRunner)并直接使用 main 方法启动测试(也由我自己初始化 Play!)时,测试运行没有问题。但我需要 JUnit 的断言方法,并且所有测试都从同一个模块运行肯定更好(我还有许多其他单元和功能测试)。 有什么想法可以解决这个问题吗? 谢谢。

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

命比纸薄 2024-12-10 20:13:37

发生的情况是 http://localhost:9000/@testshttp://localhost:9000/@tests/.class到运行占用一个线程的测试类,您的测试尝试向 http://localhost:9000/your_path 会阻塞,直到请求 http://localhost:9000/@tests/.class完成。因此,您会无限期地等待,因为默认情况下线程数为一。所以如果你增加 play.pool > 1、你的测试套件将正常工作。

请参阅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

注意:我发现有助于理解 @tests 如何工作的一件事是在 chrome 中打开网络,然后我可以轻松跟踪它的工作原理,然后更有意义地了解块所在的位置。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文