Je suis un débutant dans le concept tdd, donc ma question est, si j'ai une méthode qui appelle une autre méthode, aussi simple que cela puisse paraître, est-ce un test unitaire ou un test d'intégration? Si c'est un test d'intégration, c'est simplement parce que ma méthode appelle une autre méthode et qu'il y a une "intégration" entre les méthodes?
4 Réponses :
si j'ai une méthode qui appelle une autre méthode, aussi simple que cela puisse paraître, c'est un test unitaire ou un test d'intégration?
Malheureusement, cela dépendra de la définition de "test unitaire" et de "test d'intégration" que vous utilisez. Il y a vingt ans, lorsque ces définitions étaient élaborées par des experts dans le domaine des tests logiciels, il était plus facile de répondre à la question.
Mais le TDD s'est produit; et Kent Beck n'était pas particulièrement discipliné quant à ses définitions, et un tas de nouvelles idées ont commencé à surgir.
Même dans le contexte du TDD, il y a des désaccords subtils sur ce que signifie "test unitaire". Par exemple, une idée importante est que les tests ne doivent pas être sensibles à l'ordre dans lequel ils sont exécutés; chaque test individuel contenait toute la configuration et le démontage nécessaires pour mesurer correctement le système. Un autre était que deux tests, exécutés en même temps dans le même processus, ne devraient pas interférer l'un avec l'autre; donc aucun état mutable partagé ..
Le thème commun ici est que le test est contraint; "test unitaire" décrirait les tests qui ont un ensemble spécifique de propriétés.
Une idée différente est née de l'observation que les gros tests sont, sans une conception très soignée, fragiles pendant la durée de vie d'un projet. Si le comportement observable du sujet de test dépend à son tour de nombreuses décisions différentes qui sont susceptibles de changer, alors les tests fragiles sont un résultat courant.
Donc, un autre type de contrainte a éclaté, suggérant que les sujets de test devraient être petits - un "test unitaire" est celui dans lequel le comportement du sujet de test ne dépend que d'un nombre modeste de décisions qui pourraient potentiellement changer.
Ajoutant encore plus de confusion au mélange, les rituels que Beck et d'autres avaient utilisés avec un certain succès ont été commercialisés à plusieurs reprises sous les noms de "Test First Development", "Test Driven Development", "Test Driven Design" - ce qui a confondu le motivation. Le but est-il tester , ou est-ce le but design ?
Pour autant que je sache, tout le monde convient qu'une méthode qui ne délègue aucun de ses travaux est un bon sujet pour un test unitaire.
De plus, tout le monde s'accorde à dire qu'une méthode qui délègue son travail à des collaborateurs stables (la bibliothèque standard, par exemple) est un bon sujet pour un test unitaire.
Mais le désaccord commence lorsque nous remplaçons la conception qui n'utilise aucun collaborateur par une conception qui utilise des collaborateurs instables (en déléguant le travail à d'autres méthodes, surtout si elles sont dans des «classes» différentes).
Est-ce encore un test unitaire si nous modifions la conception pour partager le travail entre des parties instables? Je suis assez sûr que Beck dirait oui, tout comme Freeman et Pryce. Je suis moins sûr de @JBrains; voir Les tests intégrés sont une arnaque . Certains ont fait leurs propres expériences et sont parvenus à trouver des travaux pour eux; d'autres ont leur interprétation du "meilleures pratiques" décrites par leurs experts préférés.
En bref: c'est un gâchis.
La meilleure réponse que je puisse offrir est qu'au lieu de vous soucier des étiquettes que nous utilisons pour différentes saveurs de tests, concentrez-vous sur les ensembles intéressants de propriétés , les contraintes vous devez vous assurer que les tests possèdent ces propriétés et aligner ces propriétés sur leur utilisation.
Par exemple, si vous allez exécuter des tests plusieurs fois au cours d'une session de développement, en tant que mécanisme pour détecter rapidement les erreurs, vous voudrez probablement que ces tests soient rapides et indépendants de ce qui se passe dans des environnements autres que le vôtre. Pour obtenir ces propriétés, vous devez probablement éviter le trafic réseau dans vos tests, et peut-être même les E / S - faire «tout» en mémoire est beaucoup plus rapide (et vous expose à certains risques que vous devrez gérer dans autres moyens).
Une belle réponse, et merci de laisser un peu d'espace pour mettre une autre réponse ;-)
L'autre réponse est vraiment utile, mais ajoutons cette réflexion:
si j'ai une méthode qui appelle une autre méthode
Cela commence juste là. Si cette autre méthode qui est appelée vit dans votre "unité sous test", alors je la considérerais comme un test unitaire.
Si cette méthode se trouve dans "une autre" unité, (qui n'est pas "sous test", mais une "dépendance"), alors cela dépend: si vous moquez / stub cette autre unité, je pense que vous exécutez toujours une unité tester. Mais on pourrait même prétendre: lorsque cette autre unité peut simplement être appelée directement, sans stubbing, vous pouvez toujours exécuter un test unitaire sur cette pièce initiale.
En d'autres termes, vous regardez le but et la "définition" de ce que "unité" englobe: lorsque j'écris une suite de tests qui fonctionnent tous avec les méthodes publiques d'une classe Java, alors il est fort probable que ce soit tests unitaires. Peut-être que je dois stub des dépendances, peut-être que j'ai fait une excellente conception et que les unités dépendantes peuvent être utilisées sans solutions de contournement.
Le niveau "suivant" n'est cependant pas le test d'intégration. Il s'agit de tests de «fonctionnement». Au lieu de regarder "la classe X fait ceci ou cela", vous demandez "la fonctionnalité Y fonctionne-t-elle", sans vous soucier si vous n'avez besoin que de la classe X pour cela, ou de 5 autres classes. Vous vous souciez d'une fonctionnalité plus large (de bout en bout), pas d'une "unité" individuelle d'organisation du code.
Le niveau "suivant", ce serait les tests d'intégration. Dans mon livre, il s'agit de s'assurer que tout un ensemble de fonctionnalités / fonctions se réunissent, et chacun fait ce qu'il devrait faire, avec un certain accent sur les aspects qui ont été stubbed / moqués / ignorés lors du test d'unité / fonction inférieure côté des choses.
J'irais plus loin et j'essaierais d'oublier les tests "unitaires", "d'intégration", "comportementaux" ou "d'acceptation", au lieu de cela diviser tous les tests en deux groupes
En vous moquant de ressources externes ou de dépendances très compliquées, vous pouvez déplacer certains cas de test dans la catégorie "Rapide" et fournir des commentaires plus rapides au développeur.
J'essaierais de me moquer le moins possible, dans la mesure où les tests s'exécutent assez rapidement pour les exécuter après chaque modification du code.
Ensuite, "unité" deviendra une unité de comportement, qui testera le comportement de l'application et gardera l'application comme une "boîte noire" dans la mesure du possible.
Les tests d'intégration consistent à tester différents modules après l'intégration Les tests unitaires signifient que le module Test est une unité complète. À mon avis, nous l'avons appelé à la fois des tests unitaires et d'intégration
Je pense que votre question est mal formulée. De quelles méthodes parlez-vous? Appartiennent-ils tous au code testé, au test, aux deux? Mais quelle que soit la manière dont il est, il ne dit rien sur le type de test dont il s'agit et c'est la clé ici. Est-ce un test qui teste les choses indépendamment des autres? Est-ce un test qui teste plusieurs choses, comment elles fonctionnent les unes avec les autres? IOW, testez-vous la roue et le moteur séparément ou attachés?