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