集成与单元测试

Question

我正在用Grails进行开发。由于框架将引导数据并完全刷新弹出上下文，因此我发现我为服务编写了很多集成测试。让我重述一下：我发现我没有写服务的单元测试，只有集成测试。这是一个坏主意吗？我看到的唯一不足就是我的测试需要更长的时间才能运行。

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

编辑 - 要清楚，我不写集成测试，因为代码是如此复杂，只有集成测试才能做到。我编写集成测试，因为它更容易测试一切，因为框架给你很多。我嘲笑某些事情，比如如果一个服务与acegi authenticationService协作，我嘲笑它。我也会模拟任何时候我们与web服务进行交互，因为你必须为了得到一个没有特殊设置的测试。

Answer 1

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

Answer 2

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

我处于类似的情况，许多已建立的测试都是真正的集成测试，并且可能很难但并非不可能改变这种未来。

Answer 3

一般来说，重要的措施是代码覆盖率。

如果全局接口更稳定（不易改变），那么可以进行集成测试。

Answer 4

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

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

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

这不是一个很好的模式，因为您将测试推迟到项目或开发环境的后期阶段，迟早会发现一次发现错误代码已经离开了你的桌子。这意味着在解决您之前和之前应该发现的某些问题的同时，可能会阻止整个产品发布以及可能的产品发布。