Intégration vs tests unitaires

Question

Je développe avec Grails. Étant donné que le framework va amorcer des données et un contexte printanier complètement vidé, je trouve que j'écris beaucoup de tests d'intégration pour les services. Permettez-moi de reformuler cela: je trouve que je n'écris pas de tests unitaires pour les services, seulement des tests d'intégration. Est-ce une mauvaise idée? Le seul inconvénient que je vois est que mes tests prennent un peu plus de temps à courir. J'utilise les tests unitaires sur les contrôleurs, comme dans un contrôleur, je teste les différents flux d'applications, les types de résultats, la logique de redirection, etc. Mais la majorité des tests que j'écris sont des tests d'intégration. Cela semble une rupture avec les tests J2EE traditionnels, où la plupart des tests unitaires sont écrits. Edit- Pour être clair, je n'écris pas de tests d'intégration car le code est si compliqué que seuls les tests d'intégration le feront. Je suis en train d'écrire des tests d'intégration parce qu'il est plus facile de tout tester ensemble, puisque le framework vous en donne beaucoup. Je me moque de certaines choses, comme si un service collaborait avec le service d'authentification acegi, je me moque de cela. Je me moque aussi à chaque fois que nous interagissons avec un webservice, parce que vous devez pour obtenir un test qui s'exécute sans configuration spéciale.

Answer 1

Je vois clairement une tendance vers des tests plus fonctionnels et moins de tests unitaires, en particulier pour les composants fortement connectés et peu logiques. Si j'implémente un algorithme compliqué dans une classe particulière, j'écrirai généralement des tests unitaires, mais si la complexité est due à l'intégration avec d'autres composants (ce qui est très souvent le cas), les tests unitaires ne valent pas la peine.

Answer 2

Vous pouvez utiliser une structure fictive pour isoler différentes parties de vos services pour des tests individuels. Au lieu de s'appuyer sur le contexte massif de Spring, instanciez directement votre classe de service et remplissez les dépendances qui ne sont pas directement liées au test avec des simulacres. Vous pouvez avoir besoin d'un petit refactoring pour découpler vos dépendances, mais ce sera généralement pour le mieux. Cela peut conduire à écrire des tests plus nombreux et plus petits au lieu de compter sur quelques grands tests d'intégration.

Je suis dans une situation similaire où de nombreux tests établis sont vraiment des tests d'intégration, et il peut être difficile, mais pas impossible, de changer cela à l'avenir.

Answer 3

En général, la mesure importante est la couverture de code.

In peut être avantageux de faire des tests d'intégration si l'interface globale est plus stable (moins sujet à changement).

Answer 4

Vous devriez tester dès que possible, parce que vous voulez que les erreurs apparaissent le plus tôt possible, idéalement lorsque notre code est toujours sous votre propre contrôle. Plus tard, une erreur est découverte plus les coûts de la correction seront élevés. Si vous présentez une logique non triviale, vous devez tester la logique des principaux chemins de décision avec des tests unitaires, et l'exposition de cette logique et l'interaction avec les dépendances externes dans les tests d'intégration.

Si vous êtes un développeur isolé ou si vous travaillez dans une petite équipe, il est parfois difficile de distinguer les tests unitaires des tests d'intégration. Si vous travaillez dans un environnement où plusieurs équipes travaillent sur un seul produit, la logique de votre code a déjà été vérifiée (test unitaire) et vous voulez maintenant voir comment les modules jouent les uns avec les autres (test d'intégration) . Ce n'est pas un bon modèle de charger trop dans le test d'intégration, car vous reportez le test à une phase ultérieure de votre projet ou environnement de développement, et tôt ou tard, vous découvrirez que vous découvrez des erreurs une fois le code a quitté votre bureau. Cela signifiera tenir toute la libération du produit et éventuellement le produit pendant que vous corrigez quelque chose que vous auriez pu et auriez dû découvrir plus tôt.