UI 测试框架 + 持续集成？
所以我有一个继承的应用程序，我想围绕它构建一个自动化测试套件。 该应用程序在设计时并未考虑到可测试性，并且代码是一个“大泥球”。 我的计划是使用 UI 自动化测试框架，并在 UI 级别创建一套测试，直到我有足够的覆盖范围，让我能够充满信心地开始重构，并在代码中引入一些接缝，以提高可测试性和设计。
这是一个 .Net WinForms 应用程序，我知道的两个框架是：
和
根据我的阅读，这两个框架在尝试作为自动构建（持续集成）的一部分运行时都会出现问题事实上，大多数 CI 产品都作为 Windows 服务运行，如果 UI 使用模式对话框，应用程序将惨死。 我使用 CruiseControl.Net 作为我的 CI 工具。
有人有任何建议来解决这个问题吗？ 使用替代框架可以使情况变得更好？
谢谢，
迪伦
So I have an application that I inherited and I want to build up an automated test suite around it. The application wasn't designed with testability in mind, and the code is a "big ball of mud". My plan was to use a UI Automation testing framework and create a suite of tests at the UI level until I had enough coverage to allow me to start refactoring with confidence and introducing some seams into the code to improve testability and design.
It's a .Net WinForms application, and the two frameworks I'm aware of are:
and
From what I've read both frameworks pose issues when trying to run as part of an automated build (Continuous Integration) due to the fact that most CI products run as a Windows Service and if the UI uses modal dialogs the application will die a horrible death. I'm using CruiseControl.Net as my CI tool.
Does anybody have any suggestions to work around this issue? An alternative framework to use that may make the situation better?
Thanks,
Dylan
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
NUnitForms 具有“隐藏桌面”功能，可让您从 cc.net 运行单元测试。
http://automaticchainsaw.blogspot.com/2007/09/winforms -testing-using-nunitforms.html
http://automaticchainsaw.blogspot.com/2007/09/hidden -desktops-and-nunitforms.html
NUnitForms has a "hidden desktop" feature that will let you run unit tests from cc.net.
http://automaticchainsaw.blogspot.com/2007/09/winforms-testing-using-nunitforms.html
http://automaticchainsaw.blogspot.com/2007/09/hidden-desktops-and-nunitforms.html
您实际上可以通过控制台应用程序运行巡航控制，以便它可以进行交互式桌面访问。 如果服务器重新启动或崩溃，它不会自动恢复，但至少你可以做到。
也就是说，大多数人采用自动化 UI 测试（winforms、wpf 或 web）的方法是通过构建服务器运行所有非交互式测试。 一旦这些测试通过，他们就会将应用程序部署到测试环境，并针对新构建的代码版本手动触发测试运行。
这使人们有机会重置测试环境（对于 UI 测试很重要），并检查应用程序的新版本是否已正确构建以及所有单元测试是否已通过。 毕竟，如果您知道单元测试失败了，那么运行 UI 测试就没有意义了。 :-)
You can actually run cruise control via the console app so it can have interactive desktop access. It won't recover automatically if the server is rebooted or it crashes, but at least you can do it.
That said, the approach most people take with automated UI testing (winforms, wpf or web) is to run all the non-interactive tests via the build server. Once those tests pass, then they deploy the application to a test environment and manually trigger a test run against the newly built version of the code.
This gives people the chance to reset the test environment (important for UI testing) as well as check that he new version of the application was built correctly and that all unit tests passed. After all, there's no point running the UI tests if you know the unit tests fell over. :-)
我还没有尝试过，但是有 UI 自动化框架 来自微软：
I didn't try it yet, but there is the UI Automation Framework from Microsoft:
我们在控制台模式下运行持续集成验收测试，而不是作为登录虚拟 PC 中的 Windows 服务。 这对我们有用。
We ran the continuous integration acceptance tests in console mode instead of as a Windows service within a logged in Virtual PC. That worked for us.
看看这种方法。 项目的 wiki 中有详细信息。
Take a look at this approach. There is detailed information in the project's wiki.