Quelle est la différence entre les tests unitaires et les tests d'intégration? [dupliquer]
cette question a déjà une réponse ici:
Quelle est la différence entre les tests unitaires et les tests d'intégration?
y a-t-il des noms différents pour ces tests? À l'instar de certains les gens qui appellent testent des tests fonctionnels, etc.?
5 réponses
A unit test est un test écrit par le programmeur pour vérifier qu'un morceau de code relativement petit fait ce qu'il est prévu de faire. Elles sont limitées, elles doivent être faciles à écrire et à exécuter, et leur efficacité dépend de ce que le programmeur juge utile. Les tests sont destinés à l'usage du programmeur, ils ne sont pas directement utiles à quiconque d'Autre, bien que, s'ils font leur travail, les testeurs et les utilisateurs en aval devraient bénéficier de de voir de moins en moins de bugs.
une partie du fait d'être un test unitaire est l'implication que les choses en dehors du code sous test sont moquées ou égratignées. Les tests unitaires ne devraient pas dépendre de systèmes extérieurs. Ils testent la cohérence interne au lieu de prouver qu'ils jouent bien avec un système extérieur.
Un test d'intégration est fait pour démontrer que les différents éléments du système fonctionnent de concert. Les tests d'intégration couvrent l'ensemble les applications, et ils exigent beaucoup plus d'efforts à mettre en place. Ils nécessitent généralement des ressources comme des instances de base de données et du matériel pour être alloués pour eux. Les tests d'intégration font un travail plus convaincant de démonstration des travaux du système (surtout pour les non-programmeurs) qu'un ensemble de tests unitaires ne le peut, au moins dans la mesure où l'environnement de test d'intégration ressemble à la production.
en fait "test d'intégration" est utilisé pour une grande variété de choses, du système complet des tests par rapport à un environnement fait pour ressembler la production à n'importe quel test qui utilise une ressource (comme une base de données ou une file d'attente) qui n'est pas moqué.
un test unitaire ne doit pas avoir de dépendances sur le code en dehors de l'unité testée. Vous décidez de ce qu'est l'unité en recherchant la plus petite partie testable. Lorsqu'il y a des dépendances, elles doivent être remplacées par de faux objets. On se moque, talons .. Le thread d'exécution des tests commence et se termine à l'intérieur de la plus petite unité testable.
quand les faux objets sont remplacés par des objets réels et que le fil d'exécution des tests se croise dans d'autres unités testables. vous avez un test d'intégration
un essai unitaire est effectué (dans la mesure du possible) en isolation totale.
un test d'intégration est effectué lorsque l'objet ou le module testé fonctionne comme il se doit, avec d'autres bits de code.
un test unitaire teste un code sur lequel vous avez un contrôle complet, tandis qu'un test d'intégration teste comment votre code utilise ou" intègre " un autre code.
Donc vous écrire des tests unitaires pour s'assurer que votre propre bibliothèques fonctionnent comme prévu, et puis écrire des tests d'intégration pour s'assurer que votre code joue bien avec les autres codes que vous utilisez, par exemple une bibliothèque.
les tests fonctionnels sont liés aux tests d'intégration, mais en savoir plus spécifiquement aux tests qui testent un système entier ou une application avec tout le code exécuté ensemble, presque un test de super intégration.
est généralement effectué pour une seule fonctionnalité implémentée dans un module logiciel. La portée des tests est entièrement dans ce module SW. L'essai unitaire ne satisfait jamais aux exigences fonctionnelles finales. Il s'agit de la méthode de test whitebox..
alors que le test D'intégration est fait pour assurer les différentes implémentations du module SW. Les tests sont généralement effectués après l'intégration au niveau du module dans le développement SW.. Cet essai va couvrir la fonctionnelle exigences, mais pas assez pour assurer la validation du système.