集成与单元测试

Question

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

我在控制器上使用单元测试，就像在控制器中我正在测试各种应用程序流，结果类型，重定向逻辑等。但我编写的大多数测试都是集成测试。这似乎是传统J2EE测试的一个突破，其中大多数是单元测试。

编辑 - 要清楚，我不是在编写集成测试，因为代码是如此复杂，只有集成测试才会这样做。我正在编写集成测试，因为它更容易一起测试所有内容，因为框架为您提供了很多。我会模拟某些事情，比如服务与acegi authenticationService合作，我嘲笑它。我也可以随时与网络服务进行交互，因为你必须为了在没有特殊设置的情况下运行测试。

Answer 1

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

Answer 2

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

如果全局接口更稳定（更不容易改变），那么进行集成测试可能是有利的。

Answer 3

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

我处于类似的情况，其中许多已建立的测试确实是集成测试，并且要改变这种情况可能很困难，但并非不可能。

Answer 4

您应该尽快测试，因为您希望尽快显示错误，理想情况是我们的代码仍在您自己的控制之下。发现的错误越晚，修正的成本就越高。

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

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

在集成测试中加载太多不是一个好的模式，因为您将测试推迟到项目或开发环境的后期阶段，并且迟早您会发现一旦发现错误，您就会发现错误代码离开了你的办公桌。这意味着在您修复可能并且应该在之前发现的内容时，可以保留整个产品和可能的产品版本。