Windows 窗体的 Visual Studio 单元测试
我们正在 Visual Studio 2008 中开发一个项目。我们使用它提供的内置测试套件（Microsoft.VisualStudio.TestTools.UnitTesting 命名空间）。 事实证明，令我们懊恼的是，大量的复杂性（以及因此产生的错误）最终被编码到了我们的 UI 层中。 虽然我们的单元测试很好地覆盖了我们的业务层，但我们的 UI 层却是一个持续的烦恼源。 理想情况下，我们也希望对其进行单元测试。 有谁知道在 Visual Studio 中执行此操作的良好“Microsoft 兼容”方法？ 它是否会导致诸如 nUnitForms 之类的单元测试框架与 Microsoft 的东西发生某种冲突？ 对于单元测试表格，我是否应该注意任何明显的陷阱？
We're working on a project here in Visual Studio 2008. We're using the built-in testing suite provided with it (the Microsoft.VisualStudio.TestTools.UnitTesting namespace). It turns out, that much to our chagrin, a great deal of complexity (and therefore errors) have wound up coded into our UI layer. While our unit tests do a decent job of covering our business layer, our UI layer is a constant source of irritation. We'd ideally like to unit-test that, as well. Does anyone know of a good "Microsoft-compatible" way of doing that in visual studio? Will it introduce some sort of conflict to 'mix' unit testing frameworks like nUnitForms with the Microsoft stuff? Are there any obvious bear traps I should be aware of with unit-testing forms?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
您需要重构 UI，以便 UI 不需要任何单元测试。 UI 应包含最少的业务逻辑或不包含业务逻辑。 有许多模式可以处理这个问题。 Martin Fowler 有一篇非常好的文章，对这些模式进行了很多解释： http://martinfowler.com/eaaDev/ uiArchs.html
Martin Fowler 的《重构》一书中有一个小章节讨论了重构不可测试的 UI。 您还可以阅读《有效使用遗留代码》。
注意：有一些工具可用于自动化 UI 测试。 我想到了 SilkTest。 但如果可能的话我不会使用它们。
You would need to refactor the UI so that UI does not need any unit testing. UI should contain minimum or no business logic. There are many patterns that deal with this issue. Martin Fowler has a very good article that explains a lot about these patterns: http://martinfowler.com/eaaDev/uiArchs.html
There is a small chapter in the Refactoring book by Martin Fowler that talks about refactoring the non testable UI. You could also read Working Effectively With Legacy Code.
Note: There are tool that could be used to automate the UI testing. SilkTest comes to my mind. But I would not use them if possible.
这对于常规应用程序单元测试来说非常好......但是如果您正在构建需要对控件行为和状态进行单元测试的用户控件，那么它也需要一个单元测试框架。 NUnitForms 可能是您的答案 - 我个人需要亲自检查一下。
This is all well and good for regular application unit testing ... but if you are building user controls that need unit tests for the control behaviors and states, it needs a unit test framework too. NUnitForms might be the answer for you - personally I need to check it out myself.
我使用被动视图架构，详细信息如下 http://martinfowler.com/eaaDev/PassiveScreen.html
基本上将表单中的所有代码移至名为 xxxUI 的单独类中。 然后，该表单实现 IxxxUI 接口并公开 xxxUI 类所需的任何内容。 您可以简化事情并将多个控件的处理聚合到一种方法中。
然后流程进行 用户单击按钮。 该按钮调用相应 UI 类上的方法。 传递任何需要的参数。 UI 类方法修改模型。 然后使用该界面更新 UI。
对于单元测试，您可以让测试类或虚拟类实现接口并将其自身注册到 UI 类。 您可以让这些测试类触发任何类型的输入并做出相应的响应。 通常，我有按精确顺序执行操作的序列列表。 （点击 A，单击这个，滚动那个，然后键入 B，等等）。
I use the Passive View architecture as detailed here http://martinfowler.com/eaaDev/PassiveScreen.html
Basically move all your code in the forms to a separate class called the xxxUI. The form then implements a IxxxUI interface and expose anything that the xxxUI class needs. You can probably simplify things and aggregate dealing with several controls into one method.
The flow then goes The USER click on a button. The button calls a method on the corresponding UI class. Passing any needed parameters. The UI Class method modifies the model. Then using the interface updates the UI.
For unit testing you have test or dummy classes implement the interfaces and register themselves with the UI Classes. You can have these test classes fire any type of input and respond accordingly. Typically I have sequence lists that do thing in a precise order. (Tap A, click this, scroll that, then Type B, etc).
使用 ApprovalTests（www.approvaltests.com 或 nuget 批准测试）测试 Winform 非常容易，并且它们与 MsTest 以及 Nunit 兼容。
这里有一个视频介绍了如何操作：https://www.youtube.com/watch?v =hKeKBjoSfJ8
但过程很简单。
1）创建您想要在您希望验证的状态下测试的表单。
2）调用WinFormApprovals.Verify(form)
ApprovalTests使用黄金大师范例来屏幕捕获结果。 如果您喜欢，只需将文件重命名为 .approved ，测试就会通过。
对于重构现有代码来说，这样做的好处是您甚至不必担心结果是什么，因为您只关心您没有更改它。
It's quite easy to test Winforms with ApprovalTests (www.approvaltests.com or nuget approval tests) and they are compatible with MsTest as well as Nunit.
There's a video here of how to do it: https://www.youtube.com/watch?v=hKeKBjoSfJ8
But the process is simple.
1) create the form you want to test in the state you want it verified.
2) call WinFormApprovals.Verify(form)
ApprovalTests uses the golden master paradigm to screen capture the result. if you like it simply rename the file to .approved and the test will pass.
The great thing about this for refactoring existing code is you don't even have to worry about what the result is, since you are only concerned that you are not changing it.
对于 Windows 10，Microsoft 现在推荐使用 Appium 和 WinAppDriver。 VS 2019 将是包含 Microsoft 编码 UI 的最后一个版本。
https://learn.microsoft.com/en-us/visualstudio/test/use-ui-automation-to-test-your-code?view=vs-2019
For Windows 10, Microsoft now recommends Appium with WinAppDriver. VS 2019 will be the last version containing Microsoft Coded UI.
https://learn.microsoft.com/en-us/visualstudio/test/use-ui-automation-to-test-your-code?view=vs-2019
查看 Jeremy D. Miller 的 WIP 演示模式 wiki 页面 以获取重构灵感 :)
Miller 是写一本书，看起来这将是这类事情的必备之作。
Check out Jeremy D. Miller's WIP Presentation Patterns wiki page for refactoring inspiration :)
Miller is writing a book, and it looks like it's going to be a must-have for this sort of thing.
我在测试我自己的 UI 控件时使用了 NUnitForms，并取得了良好的结果！ 如果您使用标准（或经过良好测试）的 UI 控件，我会同意其他人关于重构的观点。
如果重点是测试实际控件，我会使用 NUnitForms，因为它可以扩展以支持您的新控件。 无论如何，如果您不涉及任何手动测试，您将需要一个可以对显示的最终结果进行“基于图像”分析的库。
我已经为此尝试过 TestComplete，但我认为它有点太贵了，因为我可以编写一个类似的库来仅在 c# 中进行图像比较。 因此，我的计划是单独测试控件，然后按照其他人提到的那样重构 UI。
I've used NUnitForms when it comes to testing my own UI controls with good results! I would agree with the others on refactoring if you are using standard (or well tested) UI controls.
If the focus is on testing the actual controls I would use NUnitForms as it can be extended to support your new controls. Anyhow if you're not to involve any manual testing you will need a lib that can do "image based" analysis of the displayed end result.
I've tried TestComplete for this but I though it to be a bit too pricey since I could code a similar lib for just the image comparison in c#. So my plan would be to test the controls separately and then refactor the UI as mentioned my the others.
您应该使用 Microsoft Coded UI 来测试 UI 层。 这涉及编写（或记录）模拟用户将执行的操作的测试，并编写断言语句以确保实现正确的输出。
当然，这不是单元测试是有争议的，因为很难从前端创建测试单个工作单元的操作，并且不能替代其他单元测试。 我也同意前端业务逻辑应该尽可能薄。 但是，这将填补单元测试未涵盖的任何空白。 希望您的单元测试不会覆盖较小的工作单元，以便编码的 UI 测试能够捕获剩余的未测试单元。
编码的 UI 内置于最新版本的 Visual Studio Premium。 我建议您不要只使用记录功能，而是学习如何自己编写测试，因为这会给您带来更大的灵活性。
You should use Microsoft Coded UI to test the UI layer. This involves writing (or recording) tests that mimic actions that a user would perform and writing assert statements to ensure that the correct output is achieved.
Of course, this is arguable not unit testing, because it is difficult to create actions from the front end that test a single unit of work and is not a replacement for other unit testing. I agree also that the front end business logic should be a thin as possible. However, this will fill any gaps where your unit tests do not cover. Hopefully only small units of work will be not covered by your unit tests, so that the coded UI tests will catch the remaining untested units.
Coded UI comes built in with the latest versions of Visual Studio Premium. I suggest that you do not just use the record functionality, but instead learn how to write the tests yourself as this gives you greater flexibility.