Tests unitaires et tests d'acceptation

Question

Êtes-vous pour l'un ou l'autre ? Ou les deux ?

J'entends par là les tests unitaires :

• valider le système du point de vue du développeur
• aider les développeurs à pratiquer le TDD
• conserver la modularité du code
• aider à détecter les erreurs à de faibles niveaux de granularité

Tests d'acceptation :

• valider le système du point de vue de l'entreprise et du point de vue du CQ / AQ
• ont tendance à être de haut niveau car elles sont souvent écrites par des personnes qui ne connaissent pas les rouages 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'intégrer les tests unitaires dans les tests d'acceptation ? En d'autres termes, faire en sorte que les seconds appellent les premiers. Est-ce que le fait d'aller dans la direction opposée a un sens ?

Que pensez-vous, en général, des tests unitaires par rapport aux tests d'acceptation, et de la façon de les gérer les uns par rapport aux autres ?

Answer 1

Les tests d'acceptation et d'intégration vous indiquent si votre code est fonctionnel et complet ; les tests unitaires vous indiquent où il échoue.

Si vous avez fait du bon travail avec les tests d'acceptation et d'intégration, et qu'ils passent, votre code implémente toutes les fonctionnalités qu'il est censé implémenter, et il fonctionne. C'est une bonne nouvelle (mais c'est aussi une bonne nouvelle de savoir qu'il ne fonctionne pas). Mais s'il ne fonctionne pas, un test d'acceptation ne vous donnera pas beaucoup d'informations sur ce qui ne va pas ; puisqu'il teste de nombreuses unités de fonctionnalité, il peut être une sorte de vue d'ensemble de l'échec. C'est là que les tests unitaires font merveille. Les bons tests unitaires vous disent exactement ce qui n'a pas fonctionné, avec quelle partie de votre code. Il est plus difficile de savoir si vous avez écrit suffisamment de tests unitaires que de tests d'acceptation, mais lorsque vous avez un test d'acceptation défaillant sans test unitaire défaillant correspondant, il est temps d'écrire ce test unitaire.

Tout cela est du point de vue des tests. Et, bien sûr, TDD n'est pas (et ATDD n'est pas) à propos des tests. En ce qui concerne le pilotage 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 à la prochaine intersection ("tournez à gauche"). Ils sont tous deux précieux à cet égard et, là encore, leur valeur est complémentaire.

Ne les confondez pas, ne les mélangez pas. Les tests unitaires, en particulier, ne doivent dépendre de rien d'autre, et ce serait une erreur de contraindre vos tests unitaires en rendant les tests d'acceptation dépendants d'eux. Bien sûr, ils peuvent partager une partie du code du framework, mais ils doivent être indépendants.

Answer 2

Cependant, pour minimiser le travail redondant, est-ce une bonne idée d'essayer d'intégrer les tests unitaires dans les tests d'acceptation ?

Non.

En d'autres termes, que le dernier [acceptation] appelle le premier [unité]. Est-ce que le fait d'aller dans la direction opposée a un sens ?

Ne vous donnez pas la peine.

Les tests d'acceptation sont souvent politiques. Vous les montrez à des personnes qui, sur la base de leur instinct, décident d'accepter ou de rejeter.

Ensuite, vous discutez de la validité des tests d'acceptation.

Puis vous vous disputez sur l'étendue du travail et 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 d'enjoliver la politique. Embrassez-la. Laissez les choses se faire.

---

Vous pouvez espérer que le développement piloté par les tests d'acceptation (ATDD) conduise à ce que "les tests d'acceptation soient rédigés et acceptés par l'ensemble de l'équipe avant le début du développement". Mais vous devez tenir compte de la réalité : tout ce qui est écrit à l'avance est au mieux spécieux et au pire négociable.

Le principe qui sous-tend toutes les méthodes Agile est que vous ne pouvez vous mettre d'accord que pour obtenir quelque chose de libérable. Tout ce qui suit est négociable.

La prémisse derrière tout test-first (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 vous mettre d'accord -- en principe -- sur le test résultats mais vous n'avez pas vraiment accepté le test. lui-même .

Il se peut que le test soit difficile à écrire. Ou pire, ne peut pas être écrit du tout. Vous pouvez accepter des résultats qui semblent testables, mais s'avèrent être mal définies. Que faire maintenant ? Ce sont des choses que vous ne pouvez pas savoir avant de commencer le développement et d'entrer dans les détails.

Tous les tests sont importants. Et aucun type particulier de test ne peut être un sur-ensemble ou un sous-ensemble d'un autre type de test. Ce sont toujours des ensembles qui se chevauchent partiellement. Essayer de les combiner pour économiser un peu de travail s'avérera probablement une perte de temps.

Plus de tests, c'est mieux que tout. L'union de tous les tests a plus de valeur que d'essayer de forcer une relation sous-ensemble-superset entre les tests.

Answer 3

En résumé de tout ce qui précède,

• Tests d'acceptation assurez-vous que vous construisez le bonne chose
• Tests unitaires assurez-vous que vous construisez le bonne chose

Answer 4

Tests unitaires - ma fonction spécifique fait ce qu'elle est censée faire, ni plus ni moins.

Test d'acceptation - mon application fait ce qu'elle est censée faire.

Exemple : Application permettant de calculer les racines de fonctions quadratiques. Prend les entrées 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 mon addition et ma soustraction fonctionnent correctement.

Tests d'acceptation - vérifier que mon application calcule les racines des fonctions quadratiques.

Puisque toute mon application consiste à calculer des racines, je ne devrais pas avoir un test unitaire qui calcule également des racines parce qu'il n'y a pas de fonction individuelle qui le fait.

Answer 5

Il ne s'agit que de mon opinion personnelle sur la question de certains types de tests :

Cependant, pour minimiser le travail redondant travail redondant, est-ce une bonne idée d'essayer de d'incorporer les tests unitaires dans les d'acceptation ?

Je suis d'accord avec le non de S. Lott sur ce point et j'ajouterais qu'il y a un risque que les tests unitaires soient truqués dans une certaine mesure et que certains bogues puissent passer au travers. Par exemple, dans le cas d'une liste déroulante, quelqu'un peut tester quelques états mais probablement pas tous, où un testeur peut utiliser des données différentes pour découvrir un bogue potentiel.

En d'autres termes, que le second appelle le premier. Est-ce que le fait d'aller dans la direction sens ?

Je ferais attention à ne jamais les coupler ensemble. Les tests unitaires représentent les tests des plus petits morceaux de fonctionnalité, souvent si petits qu'un utilisateur final ne comprendrait pas qu'il puisse y avoir des centaines de tests juste pour qu'un formulaire web entre des données dans un système CRM. Les tests d'acceptation portent davantage sur ce que veut l'utilisateur de l'application, ce qui peut être plus subjectif, par exemple : "Est-ce que c'est joli ?" ou "Est-ce que c'est bien ?". Il peut y avoir cette marque de "suffisamment bon" avec les tests d'acceptation qui, je ne suis pas sûr, fonctionnerait avec les tests unitaires. En général, si un test unitaire échoue, quelqu'un doit décider soit de corriger le code, soit de supprimer le test, chacun pouvant être une bonne option selon les circonstances.

Quelles sont vos réflexions en général sur les tests unitaires et les tests d'acceptation, et comment les gérer les uns par rapport aux autres l'un par rapport à l'autre ?

Les tests unitaires servent à vérifier les morceaux de code les plus simples. Il peut y avoir des tests d'intégration, mais il s'agit d'un niveau supérieur, 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 en grandissant et qui présentaient des jouets que l'on pouvait assembler comme "Voltron" ou divers Transformers comme les Constructicons qui formaient Devastator. Les tests d'acceptation se situent généralement du point de vue de l'utilisateur final : "Puis-je faire X avec l'application maintenant ?" et la réponse est "Oui" avant que l'application ne soit mise en service. Si certains cas d'erreur peuvent être vérifiés dans un test d'acceptation, il n'est pas courant d'effectuer un test approfondi de toutes les combinaisons possibles que l'on peut saisir dans une application. Cependant, les tests unitaires peuvent couvrir les conditions limites et quelques autres cas de type aléatoire.