我正在使用Grails进行开发。由于该框架会引导数据和完整的Spring上下文，因此我发现，我为服务编写了许多集成测试。让我重述一下：我认为我不需要为服务编写单元测试，只需要编写集成测试。这是一个坏主意吗？我唯一看到的缺点是我的测试需要花费更长时间。
对于控制器，我会使用单元测试来测试各种应用程序流程、结果类型、重定向逻辑等。但我编写的大部分测试都是集成测试。这似乎与传统的J2EE测试不同，那里通常只编写单元测试。
编辑-明确一下，我并不是因为代码太复杂才编写集成测试。我之所以编写集成测试，是因为一切都在框架中，因此更容易进行全面测试。我确实模拟了某些内容，例如如果服务与acegi authenticationService合作，我就会模拟它。我们与Web服务交互时，我也会进行模拟，因为您必须这样做才能运行没有特殊设置的测试。
我明显看到越来越多的功能测试和少量单元测试的趋势，特别是对于逻辑较少的高度连接组件。如果我在特定类中实现了一个复杂算法，我通常会为其编写单元测试，但如果复杂性是由与其他组件的集成引起的（这种情况非常频繁），则编写单元测试就不值得麻烦了。
通常，重要的衡量标准是代码覆盖率。
如果全局接口更稳定（不易受到更改的影响），进行集成测试可能会更有优势。
您可以使用模拟框架来隔离服务的不同部分进行单独测试。不要依赖于庞大的Spring上下文，直接实例化您的服务类，并使用模拟对象填充与测试无关的依赖项。您可能需要进行一些重构以解耦依赖项，但通常这样做会更好。这可以导致编写更多、更小的测试，而不是依赖于少数大型集成测试。
我处于类似的情况，许多已经建立的测试实际上是集成测试，改变这种情况可能会很困难，但并非不可能。
你应该尽快进行测试，因为你希望错误尽早出现，最好是在我们的代码仍然在你自己的控制下的时候。错误被发现得越晚，纠正的成本就越高。
如果你正在暴露非平凡的逻辑，你应该使用单元测试来测试主要决策路径的逻辑，并使用集成测试来测试该逻辑的暴露和与外部依赖项的交互。
如果你是一个独立开发者或在一个小团队中工作，有时很难看到单元测试和集成测试之间的区别。如果你处于多个团队共同开发一个产品的环境中，那么假设你代码内部的逻辑已经经过验证（单元测试），现在你想看看模块如何相互配合（集成测试）。
将太多内容加载到集成测试中并不是一个好的模式，因为你正在将测试推迟到项目或开发环境的后期阶段，迟早会发现一旦代码离开你的桌子，你才会发现错误。这意味着你需要暂停整个甚至可能是产品发布的进程，而你本可以和应该更早地发现并解决这些问题。
