Tests unitaires vs tests d'acceptation
Êtes-vous pour l'un ou pour l'autre? Ou les deux?
Ma compréhension est des tests unitaires:
- valider le système du point de vue du développeur
- aider les développeurs à pratiquer TDD
- garder le code modulaire
- aider à détecter les erreurs à de faibles niveaux de granularité
Tests d'acceptation:
- valider le système du point de vue commercial et QC/QA
- ont tendance à être de haut niveau car ils sont souvent écrits par des personnes qui ne connaissent pas le fonctionnement interne du code
Je pense que les deux sont nécessaires. Cependant, pour minimiser le travail redondant, est-ce une bonne idée d'essayer d'incorporer les tests unitaires dans les tests d'acceptation? En d'autres termes, demandez à ces derniers d'appeler les premiers. Est-il sensé d'aller dans la direction opposée?
Que pensez-vous en général des tests unitaires par rapport aux tests d'acceptation, et comment les gérer les uns par rapport aux autres?
Les tests d'acceptation et d'intégration vous indiquent si votre code fonctionne et est complet; les tests unitaires vous indiquent où cela échoue.
Si vous avez fait du bon travail avec les tests d'acceptation et d'intégration, et qu'ils réussissent, votre code implémente toutes les fonctionnalités qu'il est censé faire, et cela fonctionne. C'est super à savoir (c'est aussi super de savoir que ce n'est pas le cas). Mais si cela ne fonctionne pas, un test d'acceptation ne vous donnera pas beaucoup d'informations sur ce qui a mal tourné; car il teste de nombreuses unités de fonctionnalité, il peut être une sorte de vue plongeante sur l'échec. C'est là que brillent les tests unitaires. De bons tests unitaires vous indiquent exactement ce qui s'est mal passé, avec exactement quelle partie de votre code. Il est plus difficile de savoir si vous avez écrit suffisamment de tests unitaires que les tests d'acceptation, mais lorsque vous avez un test d'acceptation échoué sans un test unitaire correspondant échoué - il est temps d'écrire ce test unitaire.
C'est tout du point de vue des tests. Et, bien sûr, TDD n'est pas (et ATDD ne l'est pas) à propos des tests. En ce qui concerne la conduite de votre conception, les tests d'acceptation vous donnent une large feuille de route ("voici où vous voulez aller") tandis que les tests unitaires vous amènent à l'intersection suivante ("tournez à gauche"). Ils sont tous deux précieux à cet égard et, encore une fois, leur valeur se complète.
Ne les confondez pas; ne les confondez pas. Les tests unitaires, en particulier, ne devraient dépendre de rien d'autre, et ce serait une erreur de contraindre vos tests unitaires en faisant dépendre le test d'acceptation. Bien sûr, ils peuvent partager du code cadre, mais ils devraient être indépendants.
Cependant, pour minimiser le travail redondant, est-ce une bonne idée d'essayer d'incorporer des tests unitaires dans les tests d'acceptation?
Non.
En d'autres termes, demandez à cette dernière [acceptation] d'appeler l'ancienne [unité]. Est-il sensé d'aller dans la direction opposée?
Ne t'embête pas.
Les tests d'acceptation sont souvent politiques. Vous les montrez à des gens qui, en fonction de leur instinct, décident d'accepter ou de rejeter.
Vous discutez ensuite de la validité des tests d'acceptation.
Ensuite, vous discutez de l'étendue du travail et de la prochaine version.
Les tests d'acceptation ne sont pas - généralement - techniques. S'ils l'étaient, alors vous auriez des tests unitaires formels et ce serait tout.
N'essayez pas de raffiner la politique. Embrasse le. Laisse faire.
Vous pouvez espérer que le développement piloté par les tests d'acceptation (ATDD) mène à "des tests d'acceptation sont écrits et approuvés par toute l'équipe avant le début du développement". Mais vous devez refléter la réalité que tout ce qui est écrit à l'avance est au mieux spécieux et au pire négociable.
La prémisse derrière toutes les méthodes Agile est que vous ne pouvez accepter que quelque chose de libérable. Après cela, tout est négociable.
La prémisse derrière tout premier test (TDD, ATDD, ou autre) est qu'un test est un accord à toute épreuve. Sauf que ce n'est pas le cas. Avec n'importe quelle méthode TDD (ou ATDD), vous pouvez accepter - en principe - le test résultats, mais vous n'avez pas vraiment accepté le test lui-même.
Il peut arriver que le test ne puisse pas être facilement écrit. Ou pire, ne peut pas être écrit du tout. Vous pouvez accepter des résultats qui semblent testables, mais s'avèrent mal définis. Et maintenant? Ce sont des choses que vous ne pouvez pas savoir avant de commencer le développement et d'obtenir les détails.
Tous les tests sont importants. Et aucun type particulier de test ne peut être un sur-ensemble ou un sous-ensemble de tout autre type de test. Ce sont toujours des ensembles qui se chevauchent partiellement. Essayer de se combiner pour économiser du travail risque de se révéler une perte de temps.
Plus de tests valent mieux que toute autre chose. L'union de tous les tests a plus de valeur que d'essayer de forcer une relation sous-ensemble-sur-ensemble entre les tests.
Tests unitaires - ma fonction spécifique fait ce qu'elle est censée faire, rien de plus et rien de moins.
Test d'acceptation - ma candidature fait ce qu'elle est censée faire.
Exemple: Application pour calculer les racines de fonctions quadratiques. Prend les entrées de a, b et c, renvoie les racines x1 et x2. Cette application est construite par des fonctions que j'écris pour ajouter deux nombres, soustraire deux nombres, multiplier deux nombres, diviser deux nombres et prendre la racine carrée de deux nombres.
Tests unitaires - vérifiez que mes fonctions de division et de multiplication fonctionnent correctement, que ma racine carrée fonctionne correctement, que mes fonctions d'addition et de soustraction fonctionnent correctement.
Tests d'acceptation - vérifiez que mon application calcule les racines des fonctions quadratiques.
Étant donné que toute mon application consiste à calculer les racines, je ne devrais pas avoir de test unitaire qui calcule également les racines car il n'y a pas de fonction individuelle qui le fasse.
Pour résumer tout ce qui précède,
- Les tests d'acceptation s'assurent que vous construisez le bonne chose
- Les tests unitaires s'assurent que vous construisez le chose correcte
Ce ne sont que mon opinion personnelle sur la question de certains types de tests:
Cependant, pour minimiser le travail redondant, est-ce une bonne idée d'essayer d'incorporer des tests unitaires dans les tests d'acceptation?
J'appuierais le non de S. Lott à ce sujet et ajouterais qu'il y a un risque ici que les tests unitaires soient truqués dans une certaine mesure et que certains bogues puissent passer. Par exemple, sur une liste déroulante, quelqu'un peut tester quelques états mais probablement pas tous, où un testeur peut utiliser différentes données pour découvrir un bogue potentiel.
En d'autres termes, demandez à ces derniers d'appeler les premiers. Est-il sensé d'aller dans la direction opposée?
Je ferais attention de ne jamais les coupler ensemble. Les tests unitaires représentent des tests des plus petits bits de fonctionnalité, souvent si petits qu'un utilisateur final ne comprendrait pas qu'il peut y avoir des centaines de tests juste pour obtenir un formulaire Web pour entrer des données dans un système CRM. Les tests d'acceptation sont plus sur ce que veut l'utilisateur de l'application, ce qui peut être plus subjectif, par exemple. "Est-ce que c'est joli?" contre "Est-ce que ça a l'air bien?" Il peut y avoir cette marque de "assez bon" avec des tests d'acceptation que je ne suis pas sûr que cela fonctionnerait avec des tests unitaires. En général, si un test unitaire échoue, quelqu'un doit décider de corriger le code ou de supprimer le test, car chacun peut être une bonne option selon les circonstances.
Que pensez-vous en général des tests unitaires par rapport aux tests d'acceptation, et comment les gérer les uns par rapport aux autres?
Les tests unitaires consistent à vérifier les éléments de code les plus simples. Il peut y avoir des tests d'intégration mais c'est un niveau plus élevé car une fois que toutes les petites pièces sont vérifiées, la combinaison des pièces fonctionne-t-elle ensemble, par exemple. il y avait des dessins animés du samedi matin que je regardais grandir qui avaient des jouets qu'on pouvait assembler comme "Voltron" ou divers transformateurs comme les Constructicons qui ont formé Devastator. Les tests d'acceptation sont généralement du point de vue de l'utilisateur final, "Puis-je faire X avec l'application maintenant?" avoir une réponse "Oui", avant que quelque chose ne passe par la porte. Bien que certains cas d'erreur puissent être vérifiés dans un test d'acceptation, il n'est pas courant de faire un test approfondi de toutes les combinaisons possibles que l'on pourrait entrer dans une application. Cependant, les tests unitaires peuvent couvrir les conditions aux limites et quelques autres cas aléatoires.