如何为主要面向服务的应用程序编写有用的单元测试? [英] How do I write useful unit tests for a mostly service-oriented app?

问题描述

我已经成功地使用了单元测试一段时间，但是我开始认为它们仅对实际上执行大量逻辑的类/方法(解析器，做数学，复杂的业务逻辑)有用.考试的候选人，毫无疑问.我真的很难弄清楚如何对另一类对象使用测试:那些对象主要通过委派进行操作.

I've used unit tests successfully for a while, but I'm beginning to think they're only useful for classes/methods that actually perform a fair amount of logic - parsers, doing math, complex business logic - all good candidates for testing, no question. I'm really struggling to figure out how to use testing for another class of objects: those which operate mostly via delegation.

要点:我当前的项目负责协调许多数据库和服务.大多数类只是服务方法的集合，大多数方法执行一些基本的条件逻辑(可能是for-each循环)，然后调用其他服务.

Case in point: my current project coordinates a lot of databases and services. Most classes are just collections of service methods, and most methods perform some basic conditional logic, maybe a for-each loop, and then invoke other services.

对于这样的对象，模拟实际上是唯一可行的测试策略，因此我尽职尽责地为其中的几种设计了模拟.我真的很不喜欢，原因如下:

With objects like this, mocks are really the only viable strategy for testing, so I've dutifully designed mocks for several of them. And I really, really don't like it, for the following reasons:

1. 使用模拟来指定对行为的期望会使我每次更改类实现时都无法正常进行，即使不是那种应该对单元测试有所帮助的更改.在我看来，单元测试应该测试功能，而不是指定方法需要依次执行A，然后B，然后C和其他操作".我喜欢测试，因为我可以放心地更改某些东西，如果有什么坏处，我可以放心地进行更改-但是，模拟只是使更改任何内容的工作变得很痛苦.
2. 如果预期的行为很简单，那么编写模拟程序通常比编写类本身要耗费更多的精力.
3. 因为我在测试中使用了所有服务和组件对象的完全不同的实现，所以最后，我所有的测试都真正验证了行为的最基本框架:"if"和"for"语句仍在工作.无聊的.我不担心这些.

我的应用程序的核心实际上是所有部分如何协同工作，因此我正在考虑 完全放弃了单元测试(显然很合适的地方除外)，而转而使用外部集成测试-较难设置，涵盖的可能性较小，但实际上是在运行系统，因为这意味着要运行.

The core of my application is really how all the pieces work together, so I'm considering ditching unit tests altogether (except for places where they're clearly appropriate) and moving to external integration tests instead - harder to set up, coverage of less possible cases, but actually exercise the system as it is mean to be run.

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

I'm not seeing any cases where using mocks is actually useful.

有想法吗?

推荐答案

如果您可以编写快速而可靠的集成测试，那我就说吧. 仅在必要时才使用模拟和/或存根，以保持这种方式.

If you can write integration tests that are fast and reliable, then I would say go for it. Use mocks and/or stubs only where necessary to keep your tests that way.

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

Notice, though, that using mocks is not necessarily as painful as you described:

1. 模拟API允许您使用 loose/non-strict 模拟，该模拟将允许从被测单元到其协作者的所有调用.因此，您不需要记录所有调用，而只需记录那些需要产生测试所需结果的调用，例如方法调用中的特定返回值.
2. 使用良好的模拟API，您将只需编写少量测试代码即可指定模拟.在某些情况下，您可能会放弃使用单个字段声明或将单个注释应用于测试类的方法.
3. 您可以使用部分模拟，以便仅针对给定测试模拟服务/组件类的必要方法.无需在字符串中指定上述方法即可完成此操作.

1. Mocking APIs let you use loose/non-strict mocks, which will allow all invocations from the unit under test to its collaborators. Therefore, you don't need to record all invocations, but only those which need to produce some required result for the test, such as a specific return value from a method call.
2. With a good mocking API, you will have to write little test code to specify mocking. In some cases you may get away with a single field declaration, or a single annotation applied to the test class.
3. You can use partial mocking so that only the necessary methods of a service/component class are actually mocked for a given test. And this can be done without specifying said methods in strings.

这篇关于如何为主要面向服务的应用程序编写有用的单元测试?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！