大型 Grails 项目中的集成和单元测试

由于必须处理模拟对象，因此编写单元测试通常比大型 Grails 项目中的集成测试更复杂。这article https://www.ibm.com/developerworks/java/library/j-grails10148/甚至建议我们甚至可以完全取消单元测试，只编写集成测试，我倾向于同意这一点。

我看到的唯一缺点是与相同单元测试相比集成测试的执行速度。

根据您从事大型 Grails 项目的实际经验，您对此有何看法？

如果我们编写一个测试完全相同的方法的单元测试，并编写也测试完全相同的方法的集成测试，这是编写测试的正常方式吗？

在实际的大型 Grails 项目中，您最终得到的单元测试与集成测试的比率是多少？

您是否在未编写任何测试的情况下成功完成了大型 Grails 项目？

如果可能的话，我总是将测试编写为单元测试。我这样做是因为：

• 单元测试执行得更快
• 我更喜欢单独测试每个组件，而不是测试集成在一起的所有组件，因为这样可以更轻松地识别错误来源
• 单元测试环境更简单（例如，没有 Spring 应用程序上下文），因此与正在执行的测试无关的潜在失败源更少

我编写集成测试的一个例子是，如果我想测试我在中定义的 Spring beanresources.groovy。虽然我可以实例化该类并直接测试它，但我的测试需要知道该 bean 的当前实现类（可能会发生变化）。

从长远来看，我认为编写集成测试实际上更复杂，因为随着时间的推移维护它们的成本比单元测试更高。 Groovy/Grails 对模拟/存根有很好的支持，因此单元测试中模拟依赖关系的成本相对较低。这是我的一个单元测试中的一个真实示例，其中我：

• 嘲笑messageSource通常仅在集成测试中可用的 Spring bean
• 模拟两个命令类，以便我可以调用validate()方法，检查.errors财产等

class MyUnitTests extends GrailsUnitTestCase {

    MessageSource messageSource

    protected void setUp() {

        super.setUp()
        // mockForConstraintsTests is a method provided by GrailsUnitTestCase
        [Complex, CategoryCommand].each {mockForConstraintsTests(it)}

        // 'mockMessage' will be returned by every method call on messageSource
        messageSource = {Object[] args -> "mockMessage"} as MessageSource
    }
}