Grails Test hickups

Question

J'ai deux questions de test. Les deux sont probablement faciles à répondre. Le premier est que j'ai écrit ce test unitaire dans Grails:

void testCount() { 
    mockDomain(UserAccount) 

    new UserAccount(firstName: "Ken").save() 
    new UserAccount(firstName: "Bob").save() 
    new UserAccount(firstName: "Dave").save() 

    assertEquals(3, UserAccount.count()) 
} 

Pour une raison quelconque, je reçois 0 retourné. Ai-je oublié de faire quelque chose?

EDIT: OH, je comprends. Les contraintes de validation ont été violées, elles n'ont donc pas été stockées. Yat-il un moyen d'obtenir des commentaires ici? C'est une chose vraiment merdique d'arriver ...

La deuxième question s'adresse à ceux qui utilisent IDEA. Que devrais-je courir - les tests de junit d'IDEA, ou les cibles de grails? J'ai deux options.

En outre, pourquoi IDEA dit-il que mes tests réussissent et qu'il fournit un feu vert même si le test ci-dessus échoue réellement? Cela va vraiment me rendre fou si je dois vérifier les rapports de test en html chaque fois que je cours mes tests .....

Aide?

Answer 1

Je fais toujours object.save(failOnError: true) dans les tests pour éviter les défaillances silencieuses comme celle-ci. Cela provoque une exception si la validation échoue. Même sans base de données réelle dans un test unitaire, la plupart des contraintes seront vérifiées, bien que je préfère utiliser des tests d'intégration si je veux tester des relations complexes entre des objets de domaine.

Answer 2

Personnellement, je n'ai pas trouvé les tests Idea JUnit particulièrement utiles lorsque vous travaillez avec des grails. Il est probablement bon d'utiliser le testeur pour les tests "Unit". Pour les tests d'intégration, vous pouvez envisager de configurer une cible ant en mode «debug» pour exécuter vos tests. Au fil du temps, les tests en cours commencent à prendre tant de temps que j'ai tendance à les exécuter exclusivement à partir de la ligne de commande pour éviter les frais supplémentaires qu'IntelliJ ajoute.

En ce qui concerne votre test unitaire, je suis à peu près certain que vous devrez effectuer un test d'intégration pour obtenir un compte différent de zéro. Je ne suis pas sûr de ce que l'unité test votre utilisation exactement mais puisque GORM n'est pas amorcé dans les tests unitaires je ne suis pas sûr que l'objet de domaine mocking soutient l'incrément d'un compte.

Votre test passerait probablement comme test d'intégration à condition que vos objets de domaine soient validés.

Answer 3

add flush: true pour votre méthode de sauvegarde. Grails définit le mode de vidage de la session de mise en veille prolongée sur manuel. Ainsi, la modification n'est pas conservée après le retour de l'action mais avant que la vue ne soit rendue. Cela permet aux vues d'accéder à des collections et à des relations paresseuses et d'empêcher la persistance automatique des modifications.