Intégration vs tests unitaires
Vous devez garder vos tests unitaires et vos tests d'intégration complètement séparés. Vos tests unitaires doivent tester une seule chose et une seule chose et dans l'isolement complet du reste de votre système. Une unité est vaguement définie, mais elle se résume généralement à une méthode ou une fonction.
Il est logique d'avoir des tests pour chaque unité afin que vous sachiez que leurs algorithmes sont correctement implémentés et que vous savez immédiatement ce qui s'est mal passé, si l'implémentation est défectueuse.
Étant donné que vous testez dans l'isolement complet lors des tests unitaires, vous utilisez des objets stub et mock pour vous comporter comme le reste de votre application. C'est là que les tests d'intégration entrent en jeu. Tester toutes les unités isolément est excellent, mais vous devez savoir si les unités fonctionnent réellement ensemble.
Cela signifie savoir si un modèle est réellement stocké dans une base de données ou si un avertissement est réellement émis après l'échec de l'algorithme X.
Développement piloté par les tests
En prenant un peu de recul et en examinant le développement piloté par les tests (TDD), il y a plusieurs choses à prendre en compte.
- Vous écrivez votre test unitaire avant d'écrire réellement le code qui le fait passer.
- Vous faites passer le test, écrivez juste assez de code pour y parvenir.
- Maintenant que le test réussit, il est temps de prendre du recul. Y a-t-il quelque chose à refactoriser avec cette nouvelle fonctionnalité en place? Vous pouvez le faire en toute sécurité car tout est couvert par des tests.
Intégration en premier vs intégration en dernier
Les tests d'intégration s'intègrent dans ce cycle TDD de deux manières. Je connais des gens qui aiment les écrire à l'avance. Ils appellent un test d'intégration un test de bout en bout et définissent un test de bout en bout comme un test qui teste complètement tout le chemin d'un cas d'utilisation (pensez à configurer une application, à la démarrer, à aller vers un contrôleur, à l'exécuter, vérification du résultat, de la sortie, etc ...). Ensuite, ils commencent leur premier test unitaire, le font passer, en ajoutent un second, le font passer, etc ... Lentement de plus en plus de parties du test d'intégration réussissent également jusqu'à ce que la fonctionnalité soit terminée.
L'autre style consiste à créer un test unitaire de fonctionnalité par test unitaire et à ajouter les tests d'intégration jugés nécessaires par la suite. La grande différence entre ces deux est que dans le cas d'un test d'intégration, vous devez d'abord penser à la conception d'une application. Ce genre de désaccord avec la prémisse que TDD concerne autant la conception d'applications que les tests.
Aspects pratiques
À mon travail, nous avons tous nos tests dans le même projet. Il existe cependant différents groupes. L'outil d'intégration continue exécute d'abord ce qui est marqué comme des tests unitaires. Ce n'est que si ceux-ci réussissent que les tests d'intégration sont plus lents (car ils font de vraies demandes, utilisent de vraies bases de données, etc.).
Soit dit en passant, nous utilisons généralement un fichier de test pour une classe.
Lecture suggérée
- Développement d'un logiciel orienté objet, guidé par des tests Ce livre est un très bon exemple de la première méthodologie du test d'intégration
- L'art du test unitaire, avec des exemples dans dot.net Sur le test unitaire, avec des exemples dans dot.net: D Très bon livre sur les principes du test unitaire.
- Robert C. Martin sur TDD (Articles gratuits): Lisez également les deux premiers articles qu'il y a liés.