如何组织 Webdriver 测试
我想创建一些 Webdriver 测试来测试我的 Java Web 应用程序，但我不确定它们是否应该位于另一个项目中，或者是否应该位于我的 Web 应用程序项目中。
我还想在每次提交到 SVN 存储库时从我的 Hudson CI 服务器运行这些 Webdriver 测试 - 这会是标准做法吗？
我认为这并不重要，但我想知道其他人做什么？
I want to create some Webdriver tests to test my Java web application but I'm not sure whether they should live inside another project or if they should live inside my web application project.
I also want to run these Webdriver tests from my Hudson CI server upon every commit to my SVN repository - would this be a standard practice?
I don't think it matters too much but I would like to know what other people do?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
将项目和 Selenuim 测试分开是一个很好的做法，特别是如果您计划在 Hudson 中运行它们。这是因为此类测试将运行很长时间，并且您希望保持构建快速运行。
因此，您应该创建带有测试的单独项目，并在主项目完成后运行它 - 这一切都可以在 Hudson 中设置。您可以将项目设置为在每次提交后构建，但是您应该阅读相关的 Hudson 文档
It is a good practice to separate your project and Selenuim tests, especially if you are planning to run them in Hudson. This is because such tests will run for a long time and you would like to keep your build running fast.
So you should create separate project with tests and run it after your main project completed - it all can be set up in Hudson. An you can setup your project to be build after each commit, however you should read related Hudson documentation
我们有一个用 Java 和 Gwt 编写的大型企业应用程序，因此客户端上有很多 JS。
我们过去尝试过使用selenium来测试它，但由于它的复杂性和脆弱性，我们只做过一些冒烟测试。
现在我们用cucumber+watir+webdriver开始一个完整的UseCases Scenario测试。
测试是用 Ruby 和 Gherkin (cucumber DSL) 编写的，并针对我们的应用程序运行。
我们将其与 Hudson 集成，我们对任何错误都有很好的屏幕截图（很快也会有 .avi）
到目前为止，QA 和 BA 人员都很热心，考虑到与运行套件和继续运行相比，手动重新测试功能节省了成本，开发工作已经得到了回报。喝杯咖啡。 ;)
We have a big enterprise application written in Java and Gwt, so lots of JS on the client.
We tried in the past to use selenium to test it, but we never did more than some smoke tests because of the complexity and fragility of it.
Now we started a completed UseCases Scenario testing with cucumber+watir+webdriver.
Tests are written in Ruby and Gherkin (cucumber DSL) and run against our application.
We integrated that with Hudson and we have nice screenshots for any errors (and soon also .avi)
So far QA and BA people are enthusiast, and the developing effort already repaid itself considering the saving on retesting features manually compared to run the suite and going for a coffee. ;)
如果您正在对具有可重复用于不同页面的控件的 ASP.NET 应用程序进行测试，则为每个控件（而不是页面）创建一个类可能是有意义的。但通常您会希望每个类都特定于一个页面。并使您的页面保持其服务/功能，而不是代码中发生的情况。
这是一个很好的概述。
http://code.google.com/p/selenium/wiki/DesignPatterns
If you are making tests for an ASP.NET application with controls that are re-used for different pages, it might make sense to make a class for each control, rather than page. But normally you would want to make each class specific to a page. And keep your page to it's services/features, not what's happening in the code.
This is a good overview.
http://code.google.com/p/selenium/wiki/DesignPatterns