Quelle est la différence entre les tests unitaires, fonctionnels, d'acceptation et d'intégration (et tous les autres types de tests que j'ai omis de mentionner)?
Réponses
Trop de publicités?Selon l'endroit où vous regardez, vous obtiendrez des réponses légèrement différentes. J'ai lu sur le sujet, beaucoup, et voici mon distillation; encore une fois, ceux-ci sont légèrement laineux et d'autres peuvent être en désaccord.
Les Tests Unitaires
Les Tests de la plus petite unité de fonctionnalité, généralement une méthode/fonction (par exemple, avec une classe avec un état particulier, en appelant x la méthode de la classe qui devrait causer y arriver). Les tests unitaires doivent être centrées sur une fonction particulière (par exemple, l'appel de la méthode pop quand la pile est vide devriez jeter un InvalidOperationException
). Tout ce qu'il touche doit être fait en mémoire, ce qui signifie que le code de test et le code sous test ne doit pas:
- Appel (non négligeable) des collaborateurs
- L'accès au réseau
- Frappé d'une base de données
- Utiliser le système de fichiers
- Lancer un thread
- etc.
Toute sorte de dépendance qui est lent et difficile à comprendre / initialiser / manipuler doit être écrasé/moqué/whatevered à l'aide de techniques appropriées de sorte que vous pouvez vous concentrer sur ce que l'unité de code est en train de faire, pas ce que ses dépendances ne.
En bref, les tests unitaires sont aussi simples que possible, facile à déboguer, fiable (en raison de la réduction des facteurs externes), rapide à exécuter et de l'aider à prouver que les plus petits blocs de construction de votre programme fonctionne comme prévu avant, ils sont mis ensemble. Le problème, c'est que, même si vous pouvez prouver qu'ils fonctionnent parfaitement dans l'isolement, les unités de code peut éclater lorsqu'il est combiné qui nous amène à ...
Les Tests D'Intégration
Tests d'intégration de construire sur des tests unitaires en combinant les unités de code et de tests que la combinaison fonctionne correctement. Cela peut être soit à l'intérieur d'un système, ou la combinaison de plusieurs systèmes pour faire quelque chose d'utile. Aussi, une autre chose qui différencie les tests d'intégration des tests unitaires est l'environnement. Les tests d'intégration peut et va utiliser des threads, l'accès à la base de données ou faire tout ce qui est nécessaire pour s'assurer que tout le code et les différents changements de l'environnement fonctionne correctement.
Si vous avez construit quelque code de sérialisation et de l'unité testée ses entrailles sans toucher au disque, comment savez-vous que ça marchera quand vous êtes le chargement et l'enregistrement sur le disque? Peut-être que vous avez oublié de rincer et éliminer filestreams. Peut-être que votre fichier autorisations sont incorrectes et que vous avez testé les entrailles de l'aide dans la mémoire des ruisseaux. La seule façon de s'en assurer est de le tester "pour de vrai" à l'aide d'un environnement qui est plus proche de la production.
Le principal avantage est qu'ils vont trouver des bugs que les tests unitaires ne peut pas tels que le câblage de bugs (par exemple, une instance de classe d'Une façon inattendue reçoit une valeur null instance de B) et de l'environnement de bugs (il tourne très bien sur ma machine mono-PROCESSEUR, mais ma collègue, 4 core, la machine ne peut pas passer les tests). Le principal inconvénient est que les tests d'intégration toucher plus de code, sont de moins en moins fiables, les échecs sont plus difficiles à diagnostiquer et les tests sont plus difficiles à maintenir.
Aussi, les tests d'intégration n'est pas nécessairement de prouver qu'un ensemble complet de fonctionnalités de travaux. L'utilisateur ne peut pas les soins sur les détails internes de mes programmes, mais je fais!
Les Tests Fonctionnels
Les tests fonctionnels vérifient une caractéristique particulière de l'exactitude en comparant les résultats pour une entrée donnée par rapport à la spécification. Les tests fonctionnels ne pas se préoccuper des résultats intermédiaires ou d'effets secondaires, juste le résultat (ils ne se soucient pas qu'après avoir fait x, objet y a l'état z). Ils sont écrits à la partie de test de la norme, tels que, "l'appel de la fonction Carré(x) avec l'argument de 2 renvoie 4".
Des Tests D'Acceptation
Les tests d'acceptation semble être divisé en deux types:
Standard de tests d'acceptation implique l'exécution de tests sur le système (par exemple à l'aide de votre page web via un navigateur web) pour voir si la fonctionnalité de l'application répond à la spécification. E. g. "en cliquant sur une icône de zoom doit agrandir la vue du document de 25%." Il n'y a pas de véritable continuum de résultats, il suffit de réussite ou d'échec résultat.
L'avantage est que les tests sont décrits en anglais et en assure le logiciel, dans son ensemble, est complète. L'inconvénient est que vous avez déplacé un autre niveau, le test de la pyramide. Des tests d'acceptation touch montagnes de code, donc à la poursuite d'un échec peut être délicat.
Aussi, dans le développement agile de logiciels, tests d'acceptation des utilisateurs implique la création de tests de miroir de l'utilisateur des histoires créées par le logiciel du client au cours du développement. Si les tests réussissent, cela signifie que le logiciel doit répondre aux exigences du client et les histoires peuvent être considérées comme complètes. Un test d'acceptation suite est fondamentalement une spécification exécutable écrit dans un langage spécifique au domaine qui décrit les tests dans la langue utilisée par les utilisateurs du système.
Conclusion
Ils sont tous complémentaires. Parfois, il est avantageux de se concentrer sur un type ou à éviter entièrement. La principale différence pour moi est que certains des tests de regarder les choses d'un point de vue du programmeur, tandis que d'autres utilisent un client/utilisateur final de se concentrer.
La chose importante est que vous savez ce que ces termes signifient à vos collègues. Différents groupes se sont légèrement différentes définitions de ce qu'ils veulent dire quand ils disent "pleine de bout en bout" des tests, par exemple.
Je suis tombé sur Google système d'attribution de noms pour leurs tests récemment, et je suis plutôt du genre - ils contourner les arguments en utilisant simplement les Petites, Moyennes et Grandes. Pour décider de la catégorie de test s'inscrit dans, ils regardent quelques facteurs - combien de temps faut-il pour exécuter, est-il de l'accès au réseau, base de données, système de fichiers, les systèmes externes et ainsi de suite.
http://googletesting.blogspot.com/2010/12/test-sizes.html
J'imagine que la différence entre les Petites, Moyennes et Grandes pour votre lieu de travail actuel peut varier de Google.
Cependant, ce n'est pas seulement au sujet de la portée, mais sur l'objectif. Marque point sur les différents points de vue pour les tests, par exemple programmeur vs client/utilisateur final, ce qui est vraiment important.
Certains (relativement) récente des idées contre les excès de la moquerie pure et tests unitaires:
- https://www.simple-talk.com/dotnet/.net-framework/are-unit-tests-overused/
- http://googletesting.blogspot.com/2013/05/testing-on-toilet-dont-overuse-mocks.html
- http://codebetter.com/iancooper/2011/10/06/avoid-testing-implementation-details-test-behaviours/
- http://cdunn2001.blogspot.com/2014/04/the-evil-unit-test.html
- http://www.jacopretorius.net/2012/01/test-behavior-not-implementation.html
- Pourquoi la Plupart des Tests Unitaires est des Déchets
unité de test: le test de module individuel ou en composantes indépendantes dans une application est connu pour être de tests unitaires , les tests unitaires sera fait par le développeur.
test d'intégration: la combinaison de tous les modules et le test de l'application pour vérifier la communication et le flux de données entre les modules fonctionnent correctement ou pas , ce test a également effectué par les développeurs.
funcional test de vérification de l'individu fonctionnalités d'une application est à dire les tests fonctionnels
tests d'acceptation de ce test est effectué par l'utilisateur final ou le client si le build de l'application selon les besoins du client et les spécifications du client ceci est connu pour être de tests d'acceptation