2010-05-05 12 views
7

Existe-t-il une «meilleure pratique» ou un standard de facto avec la quantité de fonctionnalité GORM à tester dans les tests unitaires/fonctionnels? Mon point de vue est que l'on devrait probablement faire la plupart des tests de domaine en tant que tests fonctionnels afin que vous obteniez l'environnement complet des grails. Mais qu'est-ce que vous testez? Insère, met à jour, supprime? Examinez-vous les contraintes même si elles ont probablement été testées de manière plus approfondie par la version de Grails? Ou pensez-vous simplement que GORM fait ce qu'il est supposé faire et passe à d'autres parties de l'application?Quelle quantité de Grails GORM tester?

Répondre

5

Ma règle générale est de tester ce que j'écris. Par conséquent, si j'écris des méthodes personnalisées (ou des fermetures) alors je vais tester ces unités. Cette règle signifie également que je vais tester les contraintes depuis que j'ai écrit les contraintes. Pour cela, j'utilise la méthode mockForConstraintsTests() dans GrailsUnitTestCase.

Un exemple des contraintes bloquer:

static constraints = { 
     location(blank:true, nullable:true) 
     make(blank:false, nullable:false) 
     name(blank:false, nullable:false) 
     serviceTag(nullable:true) 
     purchaseDate(blank:false, nullable:false) 
     checkedDate(blank:false, nullable:false) 
     warrantyExpirationDate(nullable:true) 
     notes(blank:true, nullable:true) 
    } 

j'aurais le test unitaire des contraintes suivantes:

void test_null_constraints_are_checked() { 
     mockForConstraintsTests(Hardware) 
     def hardware = new Hardware() 
     assertFalse hardware.validate() 

     assertEquals 4, hardware.errors.getFieldErrorCount() 
     assertEquals "nullable", hardware.errors["name"] 
     assertEquals "nullable", hardware.errors["checkedDate"] 
     assertEquals "nullable", hardware.errors["purchaseDate"] 
     assertEquals "nullable", hardware.errors["make"] 
} 

Cela va attraper les fautes de frappe mes contraintes tout de suite.

Je ne teste pas enregistre, crée, met à jour, supprime sur le domaine; si ceux-ci échouent alors j'ai de plus gros problèmes!

+0

Souhaitez-vous tester les relations 1-M, etc.? –

+0

Je ne peux pas dire que je les ai testés directement à l'unité. Je les ramasse habituellement au niveau de l'intégration. – zentuit

1

Personnellement, je testerais toutes les relations complexes que je ne suis pas à 100% à l'aise avec la configuration, et tous les accesseurs pour lesquels l'implémentation par défaut est écrasée.

+0

Cela semble raisonnable, je m'inquiète juste que je suis en train de tester GORM lui-même au lieu de mon code. En ce qui concerne les choses, mes cartographies font partie de mon code et je le mets à l'épreuve. –