集成与单元测试

Question

我正在使用 Grails 进行开发。由于该框架将引导数据和完全刷新的 Spring 上下文，我发现我为服务编写了很多集成测试。让我换个说法：我发现我没有为服务编写单元测试，只编写集成测试。这是一个坏主意吗？我看到的唯一缺点是我的测试需要更长的时间才能运行。

我确实在控制器上使用单元测试，因为在控制器中我正在测试各种应用程序流、结果类型、重定向逻辑等。但我编写的大多数测试都是集成测试。这似乎与传统的 J2EE 测试有所不同，传统的 J2EE 测试主要是编写单元测试。

edit- 明确一点，我没有编写集成测试，因为代码太复杂了，只有集成测试才能做到。我编写集成测试是因为一起测试所有内容更容易，因为框架为您提供了很多。我会模拟某些事情，比如如果服务与 acegi authenticationService 协作，我会模拟它。每当我们与 Web 服务交互时，我也会模拟，因为您必须这样做才能获得无需特殊设置即可运行的测试。

Answer 1

我清楚地看到了更多功能测试和更少单元测试的趋势，特别是对于逻辑低的高度连接组件。如果我在一个特定的类中实现一个复杂的算法，我通常会为它编写单元测试，但如果复杂性是由于与其他组件的集成（这种情况非常常见），那么单元测试就不值得麻烦了。

Answer 2

一般来说，重要的衡量标准是代码覆盖率。

如果全局接口更稳定（不太容易更改），则进行集成测试可能会有优势。

Answer 3

您可以使用模拟框架来隔离服务的不同部分以进行单独测试。与其依赖大量的 Spring 上下文，不如直接实例化您的服务类并使用模拟填充与测试不直接相关的依赖项。您可能需要进行一些重构来解耦您的依赖关系，但这通常是最好的。这可能会导致编写更多更小的测试，而不是依赖于几个大型集成测试。

我处于类似的情况，许多已建立的测试实际上都是集成测试，未来改变这一点可能很困难，但并非不可能。

Answer 4

您应该尽快进行测试，因为您希望错误尽快出现，最好是在我们的代码仍在您自己控制之下的时候。越晚发现错误，纠正的成本就越高。

如果你要暴露非平凡的逻辑，你应该用单元测试来测试主要决策路径的逻辑，并在集成测试中暴露该逻辑以及与外部依赖项的交互。

如果您是一个单独的开发人员或在一个小团队中工作，有时很难看出单元测试和集成测试之间的区别。如果您处于多个团队正在开发单个产品的环境中，则假设您的代码中的逻辑已经过验证（单元测试），现在您想看看模块如何相互配合（集成测试） .

在集成测试中加载太多不是一个好的模式，因为您将测试推迟到项目或开发环境的后期阶段，并且迟早您会发现一旦发现错误代码已离开您的办公桌。这将意味着在您修复一些您可以而且应该更早发现的问题时，暂停整个版本，甚至可能是产品版本。