2010-05-24 1 views
3

Existe-t-il un moyen moins lourd de tester les contraintes? Il me semble que c'est trop de code pour tester les contraintes.Y at-il un moyen moins gonflé pour tester les contraintes dans les grails?

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

Répondre

3

Je conseille contre les essais getErrorCount(), que vous allez faire vos tests fragiles (comme vous ajoutez d'autres contraintes, vous devez vous rappeler de mettre à jour tous les cas de new BlogPost() partout dans vos cas de test). Vérifiez simplement hasErrors(). A part ça ... pour chaque contrainte, vous devez générer des données de test qui les violent, appeler la routine de validation et affirmer les erreurs. C'est le code dont vous avez besoin.

Refactorisez certaines méthodes pour supprimer la duplication. exemple:

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

Ross Niemi, un collègue de travail de la mine, a créé le Domain Expectations plugin qui utilise une belle DSL pour l'exercice et la validation de contraintes sur les objets de domaine de Grails. Nous l'utilisons sur mon lieu de travail et j'en suis très content.

0

Peut-être pas la réponse que vous voulez entendre, mais: Voulez-vous vraiment tester les contraintes définies dans votre modèle de domaine? En substance, ce que vous faites ici est de tester le cadre de validation de Grails plutôt que votre propre code. Ne vous méprenez pas, des tests sont nécessaires (surtout avec des langages dynamiques comme Groovy), mais à mon humble avis, il ne faut pas simplement tester aveuglément tout ce qui se présente. Peut-être que je ne suis pas trop un gars hardcore de TDD, mais je ne vois pas le point ici.

+0

Daniel, c'est exactement ce que je pensais. Je veux dire, quand une méthode exécute une sorte d'algorithme qui change une sorte d'état, il est logique d'écrire un test unitaire comme une sorte de test «ça ne se soucie pas de comment on le fait, mais ça se fait»: ça confirme les effets de l'algorithme. Avec des contraintes, il n'y a absolument aucune boîte noire et apparemment aucune valeur dans les tests unitaires. Pour être honnête, j'aimerais voir au moins un exemple convaincant d'écriture de tests unitaires pour les contraintes, si ce n'est pour d'autres raisons, que parce que j'aimerais utiliser le cadre de test intégré apparemment élégant. ;) –

+0

Ce n'est pas vraiment une réponse à la question et est plutôt juste un point de discussion/discussion. – Joseph

0

This blog post a une bonne description des contraintes de tests unitaires. Une chose que je n'ai pas vu ci-dessus est l'utilisation de mockForConstraintsTests() (qui élimine le besoin de mockDomain())

Et pour commenter Daniel, oui je testerais les contraintes définies dans mon modèle de domaine pour affirmer que j'ai correctement contraint le modèle de domaine. Vous faites une faute de frappe dans une déclaration de contrainte et vous ne la trouverez pas avant un test d'intégration ou fonctionnel (et en attendant cela vous rendra fou)

Questions connexes