unit-testing - 如何为主要面向服务的应用程序编写有用的单元测试？

Question

我已经成功使用了一段时间的单元测试，但我开始认为它们只对实际执行大量逻辑的类/方法有用——解析器、做数学、复杂的业务逻辑——所有测试的好候选， 没有问题。我真的很难弄清楚如何对另一类对象使用测试:那些主要通过委托(delegate)进行操作的对象。

恰当的例子:我当前的项目协调了很多数据库和服务。大多数类只是服务方法的集合，大多数方法执行一些基本的条件逻辑，可能是一个 for-each 循环，然后调用其他服务。

对于这样的对象，模拟确实是唯一可行的测试策略，所以我尽职尽责地为其中的几个设计了模拟。我真的，真的不喜欢它，原因如下:

每当我更改类实现时，使用模拟来指定对行为的期望会使事情中断，即使它不是应该对单元测试产生影响的那种更改。在我看来，单元测试应该测试功能，而不是指定“方法需要按照 A、B、C 的顺序执行，仅此而已”。我喜欢测试，因为我可以自由地改变事物，并且有信心我会知道是否有问题 - 但模拟只会让改变任何东西变得很痛苦。

如果预期的行为很简单，那么编写模拟通常比编写类本身要多。

因为我在测试中使用了完全不同的所有服务和组件对象的实现，所以最后，我所有的测试真正验证的是行为的最基本框架:“if”和“for”语句仍然有效。无聊的。我不担心这些。

我的应用程序的核心实际上是所有部分如何协同工作，所以我正在考虑
完全放弃单元测试(除了明显合适的地方)，转而使用外部集成测试——更难设置，覆盖更少的情况，但实际上运行系统，因为它意味着运行。

我没有看到任何使用模拟实际上有用的情况。

想法？

Answer 1

如果您可以编写快速可靠的集成测试，那么我会说去吧。
仅在必要时使用模拟和/或 stub 以保持测试不变。

但是请注意，使用模拟不一定像您描述的那样痛苦:

模拟 API 允许您使用松散/非严格的模拟，这将允许从被测单元到其协作者的所有调用。因此，您不需要记录所有调用，而只需要记录那些需要为测试产生一些所需结果的调用，例如方法调用的特定返回值。

使用良好的模拟 API，您将不得不编写很少的测试代码来指定模拟。在某些情况下，您可能会使用单个字段声明或应用于测试类的单个注释。

您可以使用部分模拟，以便为给定的测试仅模拟服务/组件类的必要方法。这可以在没有在字符串中指定所述方法的情况下完成。