编写单元测试通常比较复杂,因为在大型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 举报,一经查实,本站将立刻删除。