目前我想改进测试用例。由于我们已经使用MVVM切换到WPF，我正在考虑编写单元测试以使用视图模型（测试视图模型）或更好地使用编码的ui测试。有什么选择，或者正在测试两种方式？目前我找不到任何实际的答案，也许有人有一个直接的答案。
谢谢！
答案 0 :(得分：8)
单元测试和UI /系统测试是完全不同的目的。
单元测试应该在单元级别测试应用程序的正确行为（例如，此方法，给定输入 x 和 y ，应该返回值 z ），你可能会有很多这些值（在一个大型项目中有数百甚至数千或数万）。
单元测试应该写得小，快，并且可以独立于外部依赖性测试每个东西，例如数据库，Web服务，文件系统，当前日期/时间等。理想情况下，它们应该用这样的方式编写。一种唯一可能导致它们失败的原因是因为它们正在测试的代码以某种方式发生了改变，从而破坏了预期的行为。
应该经常运行好的测试，理想情况是每次开发人员在本地构建代码时，然后在代码提交后的CI过程中再次运行。一大套UI测试根本不允许你这样做。您经常运行测试的原因是因为您现在发现的错误比以后发现的错误更容易修复：开发人员在编写代码时会处理大量的上下文信息。如果他们按下＆＃34; build＆＃34;按钮和测试弹出几秒钟后失败，他们没有丢失上下文，可以轻松修复错误。
如果他们3小时后发现他们3小时前编写的代码有一个错误，那么他们可能会转移到另一个任务并失去很多上下文。要获得所有上下文需要时间，这意味着需要更长的时间来修复错误。此外，他们可能不得不放弃他们正在处理的任何新任务，导致他们失去那个任务的背景，他们必须在之后重新选择这些任务。他们修复了这个错误。
这里的核心理念是您的单元测试应该可重复和一致。您无法信任的测试是您忽略的测试，您忽略的测试完全没用。
编码的UI（以及与UI交互的所有其他类型的测试）几乎完全与单元测试完全相反：它们非常慢（几十秒而不是毫秒），它们依赖于整个系统整体正确配置和部署，它们非常脆弱，容易发生随机故障。它们通常只应用作冒烟测试，以确保应用程序已正确部署，从而验证应用程序中的一些关键路径。
如果您尝试通过UI验证业务逻辑并纠正应用程序行为，那么您将为自己设置一个悲惨的体验。测试将太慢而不能频繁运行，并且对应用程序的更改将需要不断的保姆和修复由于更改而中断的UI测试。