0
Si j'annonçais mes méthodes de test d'intégration DAO avec @Transactional, Spring Test annulerait volontiers toutes les modifications apportées à la base de données après l'exécution de chaque méthode de test. Cela semble extrêmement pratique, car je peux charger les données de test une fois avec une méthode @BeforeClass et tout le nettoyage est géré pour moi.L'annulation automatique des tests d'intégration DAO avec Spring Test est-elle une bonne pratique?
Mais je me demande si c'est une bonne pratique parce que je serais manqué l'occasion de découvrir les échecs qui se produiraient lors d'un commit. Quel est le consensus sur l'utilisation des transactions dans les tests d'intégration de dbunit de DAO pour aider à nettoyer ??
En fin de compte, j'ai été très satisfait de cette approche. En outre, le chargement des données de test une fois par CUT plutôt que par une méthode de test ne fait jamais gagner beaucoup de temps dans les tests d'intégration. Le seul gotcha dans tout cela est que JUnit @BeforeClass (stupidement) nécessite que la méthode annotée soit statique. J'ai donc dû trouver un autre moyen de charger les données de test avant chaque CUT .... J'ai écrit ma propre classe d'aide pour cela. – HDave
JUnit requiert que @BeforeClass soit statique car il crée une nouvelle instance de la classe de test avant d'appeler chaque méthode de test. Cela permet de s'assurer qu'il n'y a pas d'effets secondaires entre les tests. Chacun a sa propre instance de la classe de test. –