Есть ли менее раздутый способ проверки ограничений в Grails? - PullRequest
3 голосов
/ 24 мая 2010

Есть ли менее раздутый способ проверки ограничений?Мне кажется, что это слишком много кода для проверки ограничений.

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

Ответы [ 4 ]

3 голосов
/ 25 мая 2010

Я бы посоветовал не тестировать 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'
}
0 голосов
/ 25 мая 2010

В этом блоге есть хорошее описание ограничений модульного тестирования.Одна вещь, которую я не видел выше, это использование mockForConstraintsTests () (которое устраняет необходимость в mockDomain ())

И чтобы прокомментировать Даниэля, да, я бы протестировал ограничения, определенные в моей доменной модели, чтобы утверждатьЯ правильно ограничил модель предметной области.Вы делаете опечатку в объявлении ограничения и не найдете ее до тех пор, пока интеграция или функциональный тест (а тем временем вы не сведете с ума)

0 голосов
/ 25 мая 2010

Возможно, это не тот ответ, который вы хотите услышать, но: Вы действительно хотите проверить ограничения, определенные в вашей доменной модели? По сути, то, что вы делаете здесь, это тестирование среды валидации Grails, а не вашего собственного кода. Не поймите меня неправильно, тесты необходимы (особенно с динамическими языками, такими как Groovy), но ИМХО не следует просто слепо тестировать все, что встречается. Может быть, я не слишком хардкорный парень из TDD, но я просто не вижу в этом смысла.

0 голосов
/ 25 мая 2010

Росс Ниеми (Ross Niemi), мой коллега, создал плагин Domain Expectations , который использует хороший DSL для реализации и проверки ограничений на объекты домена grails.Мы используем его на моем рабочем месте, и я был очень доволен этим.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...