使用视图模型的单元测试或编码的ui测试 [英] Unit tests with view models or coded ui test

问题描述

目前，我想改进测试用例。由于我们已经使用MVVM切换到WPF，因此我正在考虑编写单元测试以与视图模型（测试视图模型）一起使用，或者更好地使用编码的ui测试。该采取什么选择，还是同时测试这两种方法？目前，我找不到任何实际的答案，也许有人可以直接给出答案。

Currently i want to improve out test cases. Since we had switched to WPF with MVVM i'm thinking about writing unit tests to work with view models (test view models) or better use coded ui tests. What is the choice to take, or is testing both things the way to go? Currently i could not find any practical answer, maybe some one has a straight forward answer.

谢谢！

推荐答案

单元测试和UI /系统测试在用途上完全不同。

Unit tests and UI/system tests are very different things with very different purposes.

单元测试应测试以下各项的正确行为：您在 unit 级别的应用程序（例如，在输入 x 和 y 的情况下，此方法应返回值 z ），那么您可能会有很多（大型项目中可能有数百个，即使不是成千上万个）。

Unit tests should test the proper behavior of your application at the unit level (e.g. this method, given inputs x and y, should return the value z), and you will likely have lots of them (hundreds, if not thousands or tens of thousands in a large project).

单元测试应该写得很小，快速，并且可以独立于外部依赖项（例如数据库，Web服务，文件系统，当前日期/时间等）来测试每件事。理想情况下，应以使其失败的唯一可能原因是：因为他们正在测试的代码已经以某种方式改变，从而破坏了预期的行为。

Unit tests should be written to be small, fast, and to test each thing in isolation from external dependencies such as databases, web services, the file system, the current date/time, etc. They should ideally be written in such a way that the only possible reason for them to fail is because the code that they are testing has changed in some way that has broken the expected behavior.

好的测试应该经常运行，最好是每次开发人员在本地构建代码时运行一次，然后在提交代码后的CI流程中再次运行。大量的UI测试根本不允许您这样做。您希望经常运行测试的原因是，现在发现的错误比以后发现的错误更容易修复：开发人员在编写代码时会花大量的上下文信息。如果他们按下构建按钮，并在几秒钟后失败，则弹出一个测试，表明他们没有失去上下文，可以轻松修复该错误。

Good tests should be run frequently, ideally every time the developer builds the code locally, then again during the CI process after the code is committed. A big suite of UI tests simply will not allow you to do that. The reason you want to run your tests frequently is because a bug that you find now is easier to fix than a bug you find later: Developers are juggling a ton of contextual information when they're writing code. If they press the "build" button and a test pops up as failing a few seconds later, they haven't lost that context and can easily fix the bug.

如果3小时后发现他们3个小时前编写的代码有错误，那么到那时他们可能已经转移到另一项任务上，并且损失了很多在那种情况下。恢复所有上下文需要花费时间，这意味着将需要更长的时间来修复该错误。另外，他们可能不得不搁置正在执行的任何新任务，从而导致他们也失去那个任务的上下文，在修复该错误之后，他们将不得不重新选择该上下文。

If they find out 3 hours later that the code they wrote 3 hours ago has a bug, by then they've probably moved on to a different task and lost a lot of that context. It takes time to get all of that context back, meaning it's going to take longer to fix the bug. Plus, they likely have to put aside whatever new task they're working on, causing them to lose context on that task, too, which they'll have to pick back up on after they fix the bug.

这里的核心思想是您的单元测试应该可重复和一致。您无法信任的测试就是您忽略的测试，而您完全忽略的测试是毫无用处的。

The core idea here is that your unit tests should be repeatable and consistent. A test that you can't trust is a test that you ignore, and a test that you ignore is utterly useless.

编码的UI（以及所有其他类型的测试）与UI交互）几乎在所有方面都与单元测试完全相反：它们非常慢（几十秒而不是毫秒），它们依赖于整个系统的正确配置和部署，并且非常脆弱并容易出现随机故障。通常，它们只能用作烟雾测试，以确保正确部署了应用程序，从而验证了通过该应用程序的一些关键路径。

Coded UI (and all other sorts of tests that interact with the UI) are almost the exact opposite of unit tests in every way: They are very slow (tens of seconds instead of milliseconds), they depend on the entire system as a whole being correctly configured and deployed, and they are extremely brittle and prone to random failure. They generally should be used only as smoke tests, to ensure that an application has been properly deployed, and thus validate a few critical paths through the application.

如果您尝试通过UI验证业务逻辑并纠正应用程序行为，那么您将为自己带来痛苦的体验。测试太慢而无法频繁运行，并且对应用程序的更改将需要持续的保姆和修复因更改而导致的UI测试失败。

If you try to validate business logic and correct application behavior via the UI, you are setting yourself up for a miserable experience. The tests will be too slow to run frequently, and changes to your application will require constant babysitting and fixing of UI tests that have broken as a result of the changes.

这篇关于使用视图模型的单元测试或编码的ui测试的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！