大型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
    }
}

相关文章

背景:    8月29日,凌晨4点左右,某服务告警,其中一个...
https://support.smartbear.comeadyapi/docs/soapui/steps/g...
有几个选项可用于执行自定义JMeter脚本并扩展基线JMeter功能...
Scala和Java为静态语言,Groovy为动态语言Scala:函数式编程,...
出处:https://www.jianshu.com/p/ce6f8a1f66f4一、一些内部...
在运行groovy的junit方法时,报了这个错误:java.lang.Excep...