微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

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

编写单元测试通常比较复杂,因为在大型Grails项目中必须处理模拟对象而不是集成测试.这个 article甚至表明我们甚至可以完全取消单元测试,只写集成测试,我倾向于同意.

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

从您在大型Grails项目中的实际经验,您对此有何想法?

如果我们编写测试完全相同方法的单元测试,并且还编写也测试完全相同方法的集成测试,这是编写测试的正常方式吗?

在实际的大型Grails项目中,单元测试与集成测试的比例是什么?

您是否成功完成了一个大型的Grails项目,而无需进行任何测试?

解决方法

如果可能,我总是把测试写成单元测试.我这样做是因为:

>单元测试执行得更快
>我更喜欢隔离测试每个组件,而不是测试集成在一起的所有组件,因为这样可以更容易地识别错误的源
>单元测试环境更简单(例如没有Spring应用程序环境),因此与正在执行的测试无关的潜在的故障源数量较少

我将编写一个集成测试的例子是,如果我想测试一下我在resources.groovy中定义的一个Spring bean.虽然我可以实例化该类并直接测试它,然后我的测试需要知道该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
    }
}

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐