[我们正在Visual Studio 2008中进行项目开发。我们正在使用随其提供的内置测试套件（Microsoft.VisualStudio.TestTools.UnitTesting命名空间）。事实证明，令我们非常恼火的是，大量的复杂性（以及因此而来的错误）已被编码到我们的UI层中。虽然我们的单元测试在覆盖我们的业务层方面做得不错，但是我们的UI层却是一个持续不断的困扰。理想情况下，我们也希望对此进行单元测试。有谁知道在Visual Studio中实现“与Microsoft兼容”的好方法吗？它将“冲突”单元测试框架（例如nUnitForms）与Microsoft的东西引入某种冲突吗？使用单元测试表格时，我应该注意哪些明显的陷阱？
您需要重构UI，以便UI不需要任何单元测试。 UI应该包含最少或没有业务逻辑。有许多模式可以解决此问题。马丁·福勒（Martin Fowler）的一篇很好的文章很好地解释了这些模式：http://martinfowler.com/eaaDev/uiArchs.html
[Martin Fowler的Refactoring一书中有一小章谈到了重构不可测试的UI。您也可以阅读有效地使用旧版代码。
注意：有些工具可用于自动执行UI测试。 SilkTest浮现在我的脑海。但是，如果可能，我不会使用它们。
对于常规应用程序单元测试来说，这一切都很好……但是，如果您要构建需要对控件行为和状态进行单元测试的用户控件，那么它也需要一个单元测试框架。 NUnitForms可能是您的答案-我个人需要自己检查一下。
我使用被动查看架构，详情请点击http://martinfowler.com/eaaDev/PassiveScreen.html
基本上将表单中的所有代码移到称为xxxUI的单独的类。然后，该表单实现IxxxUI接口，并公开xxxUI类所需的任何内容。您可能可以简化事情，并将处理多个控件聚合到一个方法中。
然后流程转到USER单击一个按钮。该按钮调用相应的UI类上的方法。传递任何需要的参数。 UI类方法会修改模型。然后使用该界面更新UI。
对于单元测试，您可以使用测试或虚拟类来实现接口并向UI类注册自己。您可以让这些测试类触发任何类型的输入并做出相应的响应。通常，我有顺序列表，它们以精确的顺序执行操作。 （点击A，单击此项，滚动该，然后键入B，依此类推。）
使用ApprovalTests（www.approvaltests.com或nuget批准测试来测试Winforms非常容易，并且它们与MsTest以及Nunit兼容。
查看Jeremy D. Miller的WIP Presentation Patterns wiki page以重构灵感：)
我使用NUnitForms来测试自己的UI控件具有良好的效果！如果您使用的是标准（或经过良好测试）的UI控件，我将在重构方面与其他人达成共识。
您应该使用Microsoft编码的UI来测试UI层。这涉及编写（或记录）模仿用户将要执行的动作的测试，以及编写断言语句以确保获得正确的输出。
对于Windows 10，Microsoft现在建议将Appium与WinAppDriver一起使用。 VS 2019将是包含Microsoft编码UI的最新版本。