Selon l'endroit où vous regardez, vous obtiendrez des réponses légèrement différentes. J'ai beaucoup lu sur le sujet, et voici ma distillation; encore une fois, ils sont légèrement laineux et d'autres peuvent être en désaccord.
Tests unitaires
Teste la plus petite unité de fonctionnalité, généralement une méthode / fonction (par exemple, étant donné une classe avec un état particulier, l'appel de la méthode x sur la classe devrait provoquer y). Les tests unitaires devraient être axés sur une caractéristique particulière (par exemple, appeler la méthode pop lorsque la pile est vide devrait lancer un InvalidOperationException). Tout ce qu'il touche doit être fait en mémoire; cela signifie que le code de test et le code sous test ne doivent pas:
- Appelez des collaborateurs (non triviaux)
- Accéder au réseau
- Frappez une base de données
- Utiliser le système de fichiers
- Faites tourner un fil
- etc.
Tout type de dépendance lente / difficile à comprendre / initialiser / manipuler doit être tronqué / moqué / peu importe en utilisant les techniques appropriées afin que vous puissiez vous concentrer sur ce que fait l'unité de code, pas sur ce que font ses dépendances.
En bref, les tests unitaires sont aussi simples que possible, faciles à déboguer, fiables (en raison de facteurs externes réduits), rapides à exécuter et aident à prouver que les plus petits blocs de construction de votre programme fonctionnent comme prévu avant d'être assemblés. La mise en garde est que, bien que vous puissiez prouver qu'elles fonctionnent parfaitement isolément, les unités de code peuvent exploser lorsqu'elles sont combinées, ce qui nous amène à ...
Tests d'intégration
Les tests d'intégration s'appuient sur des tests unitaires en combinant les unités de code et en vérifiant que la combinaison résultante fonctionne correctement. Cela peut être soit les entrailles d'un système, soit la combinaison de plusieurs systèmes pour faire quelque chose d'utile. En outre, l'environnement différencie les tests d'intégration des tests unitaires. Les tests d'intégration peuvent utiliser et utiliseront des threads, accéderont à la base de données ou feront tout ce qui est nécessaire pour garantir que tout le code et les différentes modifications d'environnement fonctionneront correctement.
Si vous avez construit du code de sérialisation et que l'unité a testé ses entrailles sans toucher au disque, comment savez-vous que cela fonctionnera lorsque vous chargerez et enregistrerez sur le disque? Vous avez peut-être oublié de rincer et d'éliminer les flux de fichiers. Peut-être que vos autorisations de fichiers sont incorrectes et que vous avez testé les entrailles à l'aide de flux de mémoire. La seule façon de le savoir avec certitude est de le tester «pour de vrai» en utilisant un environnement le plus proche de la production.
Le principal avantage est qu'ils trouveront des bogues que les tests unitaires ne peuvent pas tels que les bogues de câblage (par exemple, une instance de classe A reçoit de manière inattendue une instance nulle de B) et des bogues d'environnement (cela fonctionne bien sur ma machine à processeur unique, mais mon La machine à 4 cœurs de mon collègue ne peut pas passer les tests). Le principal inconvénient est que les tests d'intégration touchent plus de code, sont moins fiables, les échecs sont plus difficiles à diagnostiquer et les tests sont plus difficiles à maintenir.
De plus, les tests d'intégration ne prouvent pas nécessairement qu'une fonctionnalité complète fonctionne. L'utilisateur peut ne pas se soucier des détails internes de mes programmes, mais je le fais!
Tests fonctionnels
Les tests fonctionnels vérifient l'exactitude d'une caractéristique particulière en comparant les résultats d'une entrée donnée à la spécification. Les tests fonctionnels ne concernent pas les résultats intermédiaires ou les effets secondaires, juste le résultat (ils ne se soucient pas qu'après avoir fait x, l'objet y ait l'état z). Ils sont écrits pour tester une partie de la spécification telle que "la fonction d'appel Square (x) avec l'argument de 2 renvoie 4".
Tests d'acceptation
Les tests d'acceptation semblent être divisés en deux types:
Les tests d'acceptation standard impliquent d'effectuer des tests sur le système complet (par exemple, en utilisant votre page Web via un navigateur Web) pour voir si la fonctionnalité de l'application satisfait aux spécifications. Par exemple, "cliquer sur une icône de zoom devrait agrandir la vue du document de 25%". Il n'y a pas de véritable continuum de résultats, juste un résultat de réussite ou d'échec.
L'avantage est que les tests sont décrits en anglais simple et garantissent que le logiciel, dans son ensemble, est complet. L'inconvénient est que vous avez déplacé un autre niveau vers le haut de la pyramide de test. Les tests d'acceptation touchent des montagnes de code, donc la recherche d'un échec peut être délicate.
En outre, dans le développement de logiciels agiles, les tests d'acceptation des utilisateurs impliquent la création de tests pour refléter les histoires d'utilisateurs créées par / pour le client du logiciel pendant le développement. Si les tests réussissent, cela signifie que le logiciel doit répondre aux exigences du client et que les histoires peuvent être considérées comme complètes. Une suite de tests d'acceptation est essentiellement une spécification exécutable écrite dans un langage spécifique au domaine qui décrit les tests dans le langage utilisé par les utilisateurs du système.
Conclusion
Ils sont tous complémentaires. Parfois, il est avantageux de se concentrer sur un type ou de les éviter complètement. La principale différence pour moi est que certains des tests regardent les choses du point de vue d'un programmeur, tandis que d'autres utilisent une approche client / utilisateur final.