我在我的应用程序中使用模型 - 视图 - 演示模型，我想知道是否需要为视图创建单元测试。 （我在.net 2.0 WinForms上）
现在通常视图应该非常简单，因此不必为它创建单元测试。至少这是我从视图与演示模型（PM）分离的目标中获得的想法。而且大多数情况下我的代码也是如此。
但是，有些情况下我似乎无法避免视图中的某些逻辑。这些通常与Drag＆amp; amp;删除处理或高级UI效果（假设您正在拖动网格行，而数据网格显示占位符，其他行实时移动以指示您可以将其放在那里）。
另一方面，有时在我看来，使用控件本身比使用PM更有效，并且数据绑定将更改反映回控件。例如，我有一个数据网格，让我说我从索引5移动了一行到3.我可以在PM上调用一个方法，让网格通过数据绑定反映更改。或者我可以在控件上做到这一点。不同之处在于前一种方法迫使控件从头开始重建，而后者则不然。
您有什么经历？
答案 0 :(得分：4)
如果你的视图中有一些专门的逻辑（比如你提到的拖放），你仍然可以将它移到单独的类 - 服务中，然后可以单独进行单元测试。但有时您需要重构（或概括）代码才能实现此目的。但我们的想法是尽可能保持视图代码的精简，以便所有其他代码都可以进行单元测试。
如果你真的想用测试来覆盖视图，你仍然可以使用像White这样的一些WinForms GUI测试框架（尽管这样的测试比用mocks编写单元测试要困难得多且成本高得多）。
这是关于WinForms，MVP和单元测试的一个很好的来源：Presenter First: Organizing Complex GUI Applications for Test-Driven Development
答案 1 :(得分：3)
任何时候你有可能出错的逻辑你应该为它写一个测试（如果可以的话）。话虽如此，如果它真的没有任何手动编码逻辑，你可能可以在大多数UI上传递。只要表单映射系统正在测试或来自Microsoft或某些供应商，测试每个表单的表单映射没有多大意义
悲惨的逻辑有时会泄漏到视图中。帮助避免这种情况的一个好方法是使用Fitnesse之类的东西编写功能测试（是的，有一个.NET版本）。 Fitnesse旨在测试应用程序，作为替代用户界面，当正确完成时，人们很难在视图中放置内容。
您也可以在单元测试框架中对这些类别进行测试，但我发现分离是有用的，而且业务人员可以帮助编写和运行测试（因为它们是wiki格式）。
答案 2 :(得分：0)
我认为您将业务逻辑排除在View之外，正处于正确的轨道上。也就是说，我认为View中的表示逻辑没有错。
就个人而言，我尽量保持我的视图尽可能精简，尽可能使用数据绑定，并且通常手动测试表示逻辑（运行应用程序并完成其步调）。
在我看来，非视觉课程的单元测试非常有价值。编写用户接受，功能和/或集成测试也有价值，这些测试涵盖了系统的全部或部分交互;诸如FitNesse之类的工具（如里伯所提到的）适合这些工具。最后是GUI测试;虽然为网站自动化可能会提供一些价值，但我觉得测试维护成本超过了WinForms的好处。
但我不是专家。我肯定建议研究测试人员（不是营销人员）对GUI测试的看法，并自己决定。