使用视图模型或编码ui测试进行单元测试

单元测试和UI/系统测试是非常不同的东西，有着非常不同的目的。

单元测试应该在单元级别上测试应用程序的正确行为(例如，这个方法，给定输入x和y，应该返回值z)，并且您可能会有很多这样的测试(在大型项目中，如果没有数千或数万个，则可能有数百个)。单元测试应该写得小、快，并且独立于外部依赖项(如数据库、web服务、文件系统、当前日期/时间等)来测试每件事。理想情况下，它们应该以这样一种方式编写，即它们失败的唯一可能原因是它们正在测试的代码以某种方式更改了，从而破坏了预期的行为。

良好的测试应该经常运行，理想情况下是每次开发人员在本地构建代码时，然后在提交代码后的CI过程中再次运行。一大套UI测试根本不允许您这样做。您希望频繁运行测试的原因是，您现在发现的错误比以后发现的错误更容易修复:开发人员在编写代码时要处理大量的上下文信息。如果他们按下"构建"按钮，并在几秒钟后弹出一个失败的测试，他们并没有丢失上下文，并且可以很容易地修复错误。

如果他们在3小时后发现他们3小时前写的代码有bug，那么他们可能已经转移到另一个任务上，失去了很多上下文。取回所有的上下文需要时间，这意味着修复bug需要更长的时间。另外，他们可能不得不把他们正在处理的任何新任务放在一边，导致他们也失去了任务的上下文，他们必须在修复错误后重新开始。

这里的核心思想是你的单元测试应该是可重复的和一致的。一个你不能信任的测试是一个你会忽略的测试，而一个你忽略的测试是完全无用的。

编码UI(以及与UI交互的所有其他类型的测试)几乎在各个方面都与单元测试完全相反:它们非常慢(几十秒而不是几毫秒)，它们依赖于整个系统作为一个整体被正确配置和部署，并且它们非常脆弱，容易发生随机故障。它们通常只应用作冒烟测试，以确保应用程序已被正确部署，从而验证应用程序中的一些关键路径。

如果您试图通过UI验证业务逻辑和纠正应用程序行为，那么您将为自己设置一个悲惨的体验。测试速度太慢，无法频繁运行，对应用程序的更改将需要不断地照顾和修复由于更改而损坏的UI测试。