grails에서 제약 조건을 테스트하는 방법이 덜 비대해진 방법이 있습니까?

Question

제약 조건을 테스트하는 방법이 덜 비대화 된 방법이 있습니까? 제약 조건을 테스트하기에는 너무 많은 코드라고 생각됩니다.

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

Answer 1

당신이 (당신이 다른 제약 조건을 추가 할 때, 당신은 어디서든 테스트 케이스에 new BlogPost()의 모든 인스턴스를 갱신하는 것을 기억해야합니다) 당신의 검사 결과는 깨지기 쉬운 만들 겠지만 나는 시험 getErrorCount()에 대해 조언을 것입니다. 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' 
} 

Answer 2

로스 니에미, 내 동료는 운동과 Grails의 도메인 객체에 대한 제약 조건을 검증하기위한 좋은 DSL을 사용하는 Domain Expectations plugin를 만들었습니다. 우리는 직장에서 그것을 사용하며, 나는 그것에 매우 만족해했습니다.

Answer 3

듣고 싶은 대답이 아닐 수도 있지만, 실제로 : 도메인 모델에 정의 된 제약 조건을 테스트하고 싶습니까? 본질적으로 여기서하고있는 일은 Grails의 검증 프레임 워크를 테스트하는 것입니다. 나에게 오해하지 마라. 테스트가 필요하다. (특히 Groovy와 같은 동적 인 언어에서). IMHO는 맹목적으로 오는 모든 것을 테스트해서는 안된다. 어쩌면 나는 하드 코어 TDD 사람이 너무 많지는 않지만 단지 여기에 요점을 보지 못한다.

Answer 4

This blog post에는 단위 테스트 제약 조건에 대한 설명이 있습니다. 내가 보지 못했던 한 가지는 mockDomain()에 대한 필요성을 제거한 mockForConstraintsTests()의 사용입니다.

Daniel에 대한 의견을 말하면 제 도메인 모델에 정의 된 제약 조건을 테스트하여 정확하게 도메인 모델을 제한했습니다. 제약 조건 선언에 오타가 생기면 통합 또는 기능 테스트 (그리고 그 동안 견과가 몰리게 될 때까지)를 찾을 수 없습니다.