每个测试方法都有新的 WebDriver 实例吗？
在 Selenium-webdriver 中创建 webdriver 实例的最佳实践是什么？每个测试方法、每个测试类或每个测试运行一次？
它们的启动似乎相当（非常！）昂贵，但在测试之间保持开放状态可能会导致测试方法之间的信息泄漏。
或者是否有其他选择 - 单个 Webdriver 实例是单个浏览器窗口（不包括弹出窗口），还是有一种从给定驱动程序实例启动新窗口/会话的方法？
谢谢 马特
What's the best practice fort creating webdriver instances in Selenium-webdriver? Once per test method, per test class or per test run?
They seem to be rather (very!) expensive to spin up, but keeping it open between tests risks leaking information between test methods.
Or is there an alternative - is a single webdriver instance a single browser window (excluding popups), or is there a method for starting a new window/session from a given driver instance?
Thanks
Matt
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我发现在使用真实浏览器（例如 Firefox）时，在测试方法之间重用浏览器实例可以节省大量时间。当使用 HtmlUnitDriver 运行测试时，几乎没有什么好处。
关于不确定性测试的危险，这是完全确定性测试和您的时间之间的权衡。集成测试通常涉及这样的权衡。如果您想要完全确定性的集成测试，您还应该担心在测试运行之间清除数据库/服务器状态。
如果您要重用浏览器实例，您绝对应该做的一件事是在运行之间清除/存储 cookie。
我在tearDown() 方法中执行此操作。此外，如果您的应用程序在客户端存储任何数据，您需要清除它（可能通过 JavascriptExecutor）。对于正在测试的应用程序来说，执行此操作后它应该看起来像一个完全不相关的请求，这确实最大限度地降低了不确定行为的风险。
I've found that reusing browser instances between test methods has been a huge time saver when using real browsers, e.g. Firefox. When running tests with HtmlUnitDriver, there is very little benefit.
Regarding the danger of indeterministic tests, it's a trade-off between totally deterministic tests and your time. Integration tests often involve trade-offs like these. If you want totally deterministic integration tests you should also be worrying about clearing the database/server state in between test runs.
One thing that you definitely should do if you are going to reuse browser instances is to clear/store the cookies between runs.
I do that in a tearDown() method. Also if your application stores any data on the client side you'd need to clear that (maybe via JavascriptExecutor). To your application which is under test, it should look like a completely unrelated request after doing this, which really minimizes the risk of indeterministic behaviour.
如果您的自动化集成测试的目标是进行可重复的测试，那么我会为每个测试执行推荐一个新的 webdriver 实例。
每个测试应该独立，独立于任何其他测试或副作用。
就我个人而言，我发现比难以重现的错误更令人沮丧的是您不信任的非确定性测试。
（这对于管理测试数据本身变得更加重要，特别是当您查看可以修改持久应用程序状态的测试时，例如 CRUD 操作。）
是的，额外的测试执行时间成本高昂，但总比花时间调试您的测试数据要好。测试。
一些可能有助于抵消这种损失的解决方案是将测试直接纳入构建过程，超越持续构建到持续集成方法。
还要尝试限制集成测试的范围。如果您有大量繁重的集成测试，占用了执行时间，请尝试重构。相反，增加底层服务调用（您的业务逻辑所在）的更轻量级单元测试的覆盖范围。
If your goal of automated integration testing is to have reproducible tests, then I would recommend a new webdriver instance for every test execution.
Each test should stand alone, independent from any other test or side-effects.
Personally the only thing I find more frustrating than a hard to reproduce bug, is a non-deterministic test that you don't trust.
(This becomes even more crucial for managing the test data itself, particularly when you look at tests which can modify persistent application state, like CRUD operations.)
Yes, additional test execution time is costly, but it is better then spending the time debugging your tests.
Some possible solutions to help offset this penalty is to roll your testing directly into your build process, going beyond Continuous Build to Continuous Integration approach.
Also try to limit the scope of your integration tests. If you have a lot of heavy integration tests, eating up execution time, try to refactor. Instead, increase the coverage of your more lightweight unit tests of the underlying service calls (where your business logic is).