La principale différence, pour moi, c'est que les tests d'intégration de révéler si une fonction de travail ou est cassé, car ils soulignent le code dans un scénario proche de la réalité. Ils invoquer un ou plusieurs logiciels de méthodes ou de fonctions et de tester si ils agissent comme prévu.
À l'opposé, une Unité de test le test d'une seule méthode s'appuie souvent sur la supposition erronée que le reste du logiciel est correctement de travail, parce qu'il explicitement se moque de toutes les dépendances.
Donc, quand un test unitaire pour une méthode de mise en œuvre de certaines fonctionnalité est vert, cela ne veut pas dire que la fonction est de travail.
Disons que vous avez une méthode quelque part comme ça
public SomeResults DoSomething(someInput) {
var someResult = [Do your job with someInput];
Log.TrackTheFactYouDidYourJob();
return someResults;
}
DoSomething est très important pour votre client: c'est une fonctionnalité, la seule chose qui compte. C'est pourquoi vous avez l'habitude d'écrire un Concombre spécification de le faire valoir: vous souhaitez vérifier et communiquer la fonctionnalité fonctionne ou pas.
Feature: To be able to do something
In order to do something
As someone
I want the system to do this thing
Scenario: A sample one
Given this situation
When I do something
Then what I get is what I was expecting for
Pas de doute: si le test est réussi, vous pouvez affirmer que vous livrez un travail de fonctionnalité. C'est ce que vous pouvez appeler la Valeur de l'Entreprise.
Si vous voulez écrire un test unitaire pour DoSomething vous devriez faire semblant (à l'aide de certains simulacres) que le reste de la classe et des méthodes de travail (qui est: que, de toutes les dépendances de la méthode est d'utiliser correctement son travail), et d'affirmer votre méthode de travail.
Dans la pratique, vous faites quelque chose comme
public SomeResults DoSomething(someInput) {
var someResult = [Do your job with someInput];
<b>FakeAlwaysWorkingLog</b>.TrackTheFactYouDidYourJob();
return someResults;
}
Vous pouvez faire cela avec l'Injection de Dépendance, ou une partie d'Usine Méthode ou les Mock-Cadre ou tout simplement l'extension de la classe sous test.
Supposons qu'il y a un bug dans le Journal.DoSomething().
Heureusement, le Cornichon spec va le trouver et de le votre de bout en bout, les tests échouent.
La fonctionnalité ne fonctionne pas, parce que le Journal est cassé, pas parce que [Faire votre travail avec someInput] n'est pas fait son travail. Et, en passant, [à Faire votre travail someInput] est de l'entière responsabilité de cette méthode.
Aussi, supposons que le Journal est utilisé dans 100 autres fonctions, dans 100 autres méthodes de 100 autres classes.
Yep, 100 fonctionnalités échouent. Mais, heureusement, 100 de bout en bout, les tests échouent ainsi et de révéler le problème. Et, oui: ils disent la vérité.
C'est une information très utile: je sais que j'ai un produit cassé. C'est aussi un très déroutant de l'information: il ne me dit rien à propos de où est le problème. Il communique moi le symptôme, pas la cause.
Pourtant, DoSomething de l'unité de test est vert, parce que c'est à l'aide d'un faux Journal, construit jamais se casser. Et, oui: c'est clairement le mensonge. C'est communiquer une fracture de la fonction de travail. Comment peut-il être utile?
(Si DoSomething()'s de l'unité de test échoue, assurez-vous: [Faire votre travail avec someInput] a quelques bugs.)
Supposons que c'est un système avec une fracture de la classe
![A system with a broken class]()
Un seul bug va briser plusieurs fonctionnalités, et plusieurs tests d'intégration échoue
![A single bug will break several features, and several integration tests will fail]()
D'autre part, le même bug briser d'une seule unité de test
![The same bug will break just one unit test]()
Maintenant, comparer les deux scénarios.
Le même bug briser d'une seule unité de test
- Toutes vos fonctions à l'aide de l'cassé Journal sont rouges
- Tous les tests unitaires sont de couleur verte, seule l'unité de test pour les Journaux est le rouge
En fait, les tests unitaires pour tous les modules, à l'aide d'une fracture de la fonction de green car, en utilisant des objets fantaisie, ils ont enlevé les dépendances. En d'autres termes, ils s'exécutent dans un idéal, entièrement fictif monde. Et c'est le seul moyen d'isoler les bugs et de les chercher. Les tests unitaires moyens de moqueries. Si vous n'êtes pas vous moquer, vous n'êtes pas de tests unitaires.
La différence
Les tests d'intégration dire ce quin'est pas le travail. Mais ils ne sont d'aucune utilité dans le deviner d'où le problème pourrait être.
Les tests unitaires sont les seuls tests que vous dire où exactement le bug est. Le dessin de cette information, ils doivent exécuter la méthode dans un moqué de l'environnement, où toutes les autres dépendances sont censés fonctionner correctement.
C'est pourquoi je pense que votre phrase "Ou est-ce juste un test unitaire qui s'étend sur 2 classes" est en quelque sorte déplacées. Un test unitaire ne doit jamais s'étend sur 2 classes.
Cette réponse est essentiellement un résumé de ce que j'ai écrit ici: tests Unitaires mensonge, c'est pourquoi je les aime.
