大型Grails项目中的集成和单元测试 [英] Integration and unit tests in large Grails project

问题描述

由于不得不处理模拟对象而不是在大型的Grails项目中进行集成测试，编写单元测试通常会更复杂。这篇文章甚至建议我们甚至可以完全废除单元测试，只写集成测试我倾向于同意。

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

对于从大规模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是由GrailsUnitTestCase提供的一种方法
 [Complex，CategoryCommand] .each {mockForConstraintsTests（it）} 
 
 // messageSource 
 messageSource = {Object [] args  - >]中的每个方法调用将返回'mockMessage' mockMessage} as MessageSource 
} 
} 
  

It is usually more complicated to write unit tests due to having to deal with mock objects than integration tests in a large Grails project. This article even suggests we can even do away with unit tests altogether and write only integration tests which I tend to agree.

The only disadvantage I see is the speed of execution for integration test as compared to same unit test.

What are your thoughts about this from your actual experience working on a large scale Grails project?

If we write a unit test that tests exactly same method and also write integration test that also tests exactly same method, is this normal way of writing tests?

What you ended up with in terms of ratio of unit tests to integrations tests in actual large Grails project?

Have you successfully completed a large Grails project without writing any tests?

解决方案

I always write my tests as unit tests if possible. I do this because:

• unit tests execute quicker
• I prefer to test each component in isolation, rather than testing all the components integrated together, because this makes it easier to identify the source of an error
• the unit testing environment is simpler (e.g. no Spring application context), so there are fewer potential sources of failure that are unrelated to the test being performed

An example of where I would write an integration test is if I want to test a Spring bean that I've defined in resources.groovy. Although I could instantiate the class and test it directly, my test would then need to know the current implementation class of that bean (which might change).

In the long-run I think it's actually more complicated to write integration tests, because the cost of maintaining them over time is higher than unit tests. Groovy/Grails has excellent support for mocking/stubbing, so the cost of mocking dependencies in unit tests is relatively low. Here's a real-world example from one of my unit tests where I:

• mock the messageSource Spring bean that would normally only be available in an integration test
• mock two command classes such that I can call the validate() method, inspect the .errors property, etc.

---

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

这篇关于大型Grails项目中的集成和单元测试的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！