当使用MVVM pattern 构建您的 WPF 应用程序时，您应该从视图和代码隐藏文件中获取所有业务逻辑。正确执行此操作，View 本身将是一个简单的外观，其中包含与 ViewModel 类的数据绑定和命令绑定 - 这就是魔法发生的地方。
使用 MVVM 模式构建应用程序的一个关键好处是，您可以在 ViewModel 层正确测试代码，因此您可以对系统的基本部分进行单元测试。但是，视图中仍然存在潜在的错误。例如。 “点击这个按钮真的会触发这个带有预期参数的特定功能吗？”等
对于视图中有关单元测试的功能，理想情况下会做些什么？假设您会做对，并且不花时间进行单元测试？或者我实际上也应该对此进行测试？这些应该如何创建？ ..
【问题讨论】：
标签： .net wpf unit-testing mvvm
正如您所说，您使用 ViewModel 测试所有逻辑和行为，包括“可见性”计算等行为。
一旦您完成了所有测试，那么测试视图就不再是一项任务了——您实际上是在测试事情是否“连接”正确。这种类型的测试对于手动测试人员来说很简单，因为它们本质上是在测试东西被点击时出现并“做事”（过度简化，但你明白了）。
如果您想自动化视图/交互式测试，请查看Project White，它可以让您通过很少的工作自动化您的应用程序。让您的项目与 White 完美配合的一个优势是，您还可以让辅助技术更易于访问。
【讨论】：
对于 WPF gui 测试，请尝试 IcuTest。
您可以轻松创建显示窗口和单击按钮的单元测试。
【讨论】：
MVVM 如此重要的原因之一是回归测试 UI 是一个难以解决且成本高昂的问题。绝大多数 UI 测试条件都采用“当我执行此操作时，我应该在屏幕上看到它”的形式，并且自动化第二部分并非易事。
从测试的角度来看，MVVM 为您提供的是视图模型的单元测试主体本质上是作为合同运行的。它不是正式的合同，但它的功能就像一个合同。如果你已经正确地测试了你的视图，并且你的视图模型测试足够详细，你就不需要在每次改变你的视图模型时重新测试你的视图；只要视图模型通过了它的测试，它的行为（就视图而言）就不应该改变。
但为了让它发挥作用，您必须对视图模型测试充满信心。而且它不会 100% 有效。
【讨论】：