有没有一种不那么臃肿的方法来测试 grails 中的约束？答案

【问题标题】：is there a less bloated way to test constraints in grails?有没有一种不那么臃肿的方法来测试 grails 中的约束？
【发布时间】：2010-05-24 19:00:20
【问题描述】：

有没有一种不那么臃肿的方法来测试约束？在我看来，测试约束的代码太多了。

class BlogPostTests extends GrailsUnitTestCase {

    protected void setUp() {
        super.setUp()
        mockDomain BlogPost
    }

    void testConstraints() {
        BlogPost blogPost = new BlogPost(title: "", text: "")
        assertFalse blogPost.validate()
        assertEquals 2, blogPost.errors.getErrorCount()
        assertEquals "blank", blogPost.errors.getFieldError("title").getCode()
        assertEquals "blank", blogPost.errors.getFieldError("text").getCode()

        blogPost = new BlogPost(title: "title", text: ObjectMother.bigText(2001))
        assertFalse blogPost.validate()
        assertEquals 1, blogPost.errors.getErrorCount()
        assertEquals "maxSize.exceeded", blogPost.errors.getFieldError("text").getCode()
    }
}

【问题讨论】：

标签： unit-testing grails constraints

【解决方案1】：

我建议不要测试 getErrorCount()，因为您会使您的测试变得脆弱（当您添加其他约束时，您必须记住在测试用例中的任何位置更新 new BlogPost() 的每个实例）。只需检查hasErrors()。

除此之外......对于每个约束，您需要生成一些违反它的测试数据，调用验证例程，并对错误进行断言。这是您需要的代码。

重构一些方法来删除重复。示例：

private void assertConstraintWorks(clazz, fieldName, testData, expectedErrorCode) {
    def instance = clazz.newInstance((fieldName): testData)
    assertFalse instance.validate()
    assertTrue instance.hasErrors()
    assertEquals expectedErrorCode, instance.errors?.getFieldError(fieldName)?.code
}

void testConstraints() {
    assertConstraintWorks BlogPost, 'title', '', 'blank'
    assertConstraintWorks BlogPost, 'text', '', 'blank'
    assertConstraintWorks BlogPost, 'text', ObjectMother.bigText(2001), 'maxSize.exceeded'
}

【讨论】：

【解决方案2】：

Ross Niemi，我的一个同事，创建了Domain Expectations plugin，它使用一个很好的 DSL 来执行和验证对 grails 域对象的约束。我们在工作场所使用它，我对此非常满意。

【讨论】：

【解决方案3】：

也许不是您想听到的答案，而是：您真的想测试您的域模型中定义的约束吗？本质上，您在这里所做的是测试 Grails 的验证框架，而不是您自己的代码。不要误会我的意思，测试是必要的（尤其是像 Groovy 这样的动态语言），但恕我直言，不应该只是盲目地测试遇到的一切。也许我只是不太喜欢 TDD 的铁杆人，但我看不出这里有什么意义。

【讨论】：

丹尼尔，这正是我的想法。我的意思是，当一个方法执行某种改变某种状态的算法时，将单元测试编写为一种“不在乎你如何做，而是把它完成”的测试是有意义的：它确认算法的效果。有了约束，绝对没有黑盒，显然在单元测试中没有价值。老实说，如果没有其他原因，我希望看到至少一个令人信服的例子来为约束编写单元测试，因为我喜欢使用看似优雅的内置测试框架。 ;)
这并不是问题的真正答案，而只是一个辩论/讨论点。

【解决方案4】：

This blog post 对单元测试约束有很好的描述。我在上面没有看到的一件事是使用 mockForConstraintsTests() （它消除了对 mockDomain() 的需要）

要评论 Daniel，是的，我会测试在我的域模型中定义的约束，以断言我已经正确地约束了域模型。您在约束声明中打错字，直到集成或功能测试才发现它（同时会让您发疯）

【讨论】：