目前我想改进测试用例。由于我们已经使用 MVVM 切换到 WPF，我正在考虑编写单元测试以使用视图模型（测试视图模型）或更好地使用编码的 ui 测试。采取什么选择，或者测试这两种方法是要走的路？目前我找不到任何实际的答案，也许有人有一个直截了当的答案。
谢谢！
【问题讨论】：
标签： c# wpf unit-testing mvvm coded-ui-tests
单元测试和 UI/系统测试是非常不同的东西，目的也非常不同。
单元测试应该在 unit 级别测试您的应用程序的正确行为（例如，这个方法，给定输入 x 和 y，应该返回值 z），您可能会有很多（在大型项目中可能有数百个，如果不是数千个或数万个）。
单元测试应该写得小而快，并且要独立于外部依赖项（例如数据库、Web 服务、文件系统、当前日期/时间等）来测试每件事。理想情况下，它们应该以这样的方式编写他们失败的唯一可能原因是因为他们正在测试的代码已经以某种方式发生了变化，从而破坏了预期的行为。
良好的测试应该经常运行，最好是每次开发人员在本地构建代码时，然后在提交代码后的 CI 过程中再次运行。一大套 UI 测试根本不允许您这样做。您想要频繁运行测试的原因是因为您现在发现的错误比以后发现的错误更容易修复：开发人员在编写代码时需要处理大量的上下文信息。如果他们按下“构建”按钮并在几秒钟后弹出测试失败，他们并没有丢失该上下文并且可以轻松修复错误。
如果他们在 3 小时后发现他们在 3 小时前编写的代码有错误，那么到那时他们可能已经转移到不同的任务并丢失了很多上下文。恢复所有上下文需要时间，这意味着修复错误需要更长的时间。另外，他们可能不得不搁置他们正在处理的任何新任务，导致他们也失去关于那个任务的上下文，他们必须在修复错误后重新开始.
这里的核心思想是你的单元测试应该是可重复的和一致的。一个你不能信任的测试是一个你忽略的测试，一个你忽略的测试是完全没用的。
编码的 UI（以及与 UI 交互的所有其他类型的测试）在各个方面几乎都与单元测试完全相反：它们非常慢（几十秒而不是几毫秒），它们依赖于整个系统一个整体被正确配置和部署，它们非常脆弱并且容易发生随机故障。它们通常应仅用作冒烟测试，以确保应用程序已正确部署，从而验证通过应用程序的一些关键路径。
如果您尝试通过 UI 验证业务逻辑并纠正应用程序行为，那么您的体验就会很糟糕。测试将太慢而无法频繁运行，并且对应用程序的更改将需要不断地照看和修复因更改而损坏的 UI 测试。
【讨论】：