Comment les gens entretiennent-ils leur suite de tests?

En particulier, je suis curieux des aspects suivants:

Comment savez-vous que vos cas de test sont incorrects (ou obsolètes) et doivent être réparés (ou jetés)? Je veux dire, même si un cas de test devenait invalide, il pourrait toujours passer et rester silencieux, ce qui pourrait vous faire croire à tort que votre logiciel fonctionne bien. Alors, comment réalisez-vous de tels problèmes de votre suite de tests?
Comment savez-vous que votre suite de tests n'est plus suffisante et que de nouveaux cas de tests doivent être ajoutés? Je suppose que cela a quelque chose à voir avec les changements d'exigences, mais existe-t-il une approche systématique pour vérifier l'adéquation de la suite de tests?

testing maintenance

— Ida
source

Pour paraphraser: qui teste les tests?

— Konrad Rudolph

Une bonne question pour Software Quality Assurance and Testing.sx

— Monica - M. Schröder

Réponses:

Réponse courte: utilisez des outils connus qui aident à maintenir la qualité des cas de test, tels que la couverture de code et les outils de qualité de code suivants: Cobertura, PMD, Sonar, etc. qui vous aideront à remarquer lorsqu'un composant critique du programme n'est pas suffisamment testé. De plus, écrivez des tests d'intégration, qui sont les plus susceptibles de se casser en premier en cas de problème.

Longue réponse:

Comment savez-vous que vos cas de test sont incorrects (ou obsolètes) et doivent être réparés (ou jetés)? Je veux dire, même si un cas de test devenait invalide, il pourrait toujours passer et rester silencieux, ce qui pourrait vous faire croire à tort que votre logiciel fonctionne bien. Alors, comment réalisez-vous de tels problèmes de votre suite de tests?

En utilisant des outils de couverture de code tels que Cobertura , vous pouvez détecter que les cas de test pour une classe donnée ou des méthodes complexes ne sont plus suffisants. Vous n'avez pas besoin d'atteindre une couverture de code à 100% partout et dans la plupart des cas, ce sera difficile à réaliser et pas nécessairement utile; mais les tests pour les aspects les plus critiques d'un programme doivent être maintenus avec un objectif d'au moins 80% de couverture de code.
En utilisant des outils de construction et d'intégration continus , tels que Jenkins que j'aime beaucoup, en combinaison avec le plugin Sonar , vous pouvez définir des déclencheurs qui envoient des e-mails et d'autres types d'alertes aux personnes responsables des dernières modifications. Divers graphiques et statistiques (Sonar utilise également Cobertura parmi de nombreux autres outils) aident les réviseurs de code et les développeurs de cas de test à se concentrer sur ce qui est essentiel.

Comment savez-vous que votre suite de tests n'est plus suffisante et que de nouveaux cas de tests doivent être ajoutés? Je suppose que cela a quelque chose à voir avec les changements d'exigences, mais existe-t-il une approche systématique pour vérifier l'adéquation de la suite de tests?

Ce que j'ai écrit pour la première question fait partie de la réponse à votre deuxième question. J'ajouterai également les points suivants ici:

Écrivez des cas de test d'intégration (ou des cas «d'affaires» si vous préférez) en plus des cas de test. Celles-ci sont les plus susceptibles de changer / casser en premier car elles dépendent souvent de plusieurs classes / méthodes. Et comme ils se cassent souvent, il est moins probable qu'ils seront oubliés. La seule approche / méthodologie qui, d'après mon expérience personnelle, aide à rédiger de bons tests est le développement piloté par les tests . Surtout si la personne qui écrit le cas de test n'est PAS la même personne qui écrit le code pour cela. Écrire de bons cas de test en utilisant TDD prend également du temps, mais les résultats, au moins pour moi, étaient extrêmement satisfaisants.
Chaque fois qu'un bogue sort, écrivez le correctif et le cas de test qui l'accompagne. Le cas de test ne devrait couvrir que ce bogue particulier. Puisque vous avez complètement couvert le code responsable du bogue, il ne devrait plus apparaître.

— Jalayn
source

Je suis d'accord avec tout sauf que la personne qui écrit le test n'est pas la même personne qui écrit le code. Cela semble bon en théorie, et ce serait bien si ce n'était pas si inefficace. Peu importe à quel point votre base de code est impressionnante, si elle est de n'importe quelle taille, cela prend quelques heures juste pour se familiariser avec la façon dont une partie de celle-ci fonctionne. fonctionne, il faut que quelqu'un d'autre entre et apprenne un peu ses entrées et sorties, puis passe un test. Si la qualité du code n'est pas la meilleure, cela pourrait prendre des jours pour écrire un test complet

— Earlz

@Earlz Je suis d'accord avec vous si les deux personnes ne travaillent pas sur le même projet. Si les deux développeurs travaillent sur le même projet, qui utilise sans doute de manière cohérente le même cadre, les mêmes bibliothèques et la même méthodologie de développement, il ne devrait avoir aucun problème, SAUF s'il s'agit d'une exigence commerciale complexe.

— Jalayn

@Jalayn pour mon cas, le produit est juste très complexe. La qualité du code n'est pas la meilleure, mais ce n'est certainement pas la pire (nous effectuons une refactorisation régulière). Nous imposons d'avoir un testeur séparé, mais pour les tests unitaires, la personne qui a terminé le travail le fait. Notre produit se compose de centaines (voire de milliers?) De cours traitant d'un sujet complexe, l'obscurcissement.

— Earlz

@Jalayn Merci d'avoir mentionné ces outils. Mais comme pour l'outil de couverture, vous ne pouvez pas l'exécuter tout le temps, non? Alors à quel moment il est nécessaire d'exécuter un tel outil? Après plusieurs modifications du code source? Ou après quelques mises à jour de test? Existe-t-il une directive commune à ce sujet?

— Ida

Eh bien, si vous avez un serveur de build continu, vos applications peuvent être construites et testées chaque fois que quelque chose est validé dans le référentiel (nous le faisons au travail). Il est configurable, vous pouvez aussi par exemple construire toutes les 15 minutes. Quant à la couverture du code, elle est activée lors des cas de test et n'ajoute pas beaucoup de surcharge. Cependant, les builds avec des contrôles de qualité de code complets activés, comme Sonar, prennent généralement très longtemps, ceux-ci sont exécutés tous les soirs par exemple. Idéalement, vous ne devriez pas avoir à exécuter ces outils manuellement.

— Jalayn

Il n'y a vraiment aucun moyen de s'assurer que vos cas de test sont corrects, sauf en se concentrant vraiment bien lors de leur création - comprendre les exigences, comprendre le code et s'assurer qu'ils sont d'accord. Le point d'avoir une suite de tests est que vous ne devez le faire qu'une seule fois, et à partir de là, vous pouvez simplement réexécuter les tests et vérifier qu'ils passent, alors que sans une suite de tests, vous devrez vous concentrer très dur tout le temps , c'est-à-dire chaque fois que vous faites quoi que ce soit à votre base de code. Mais le problème fondamental de devoir vous assurer que vous avez fait la bonne chose en premier lieu demeure - les ordinateurs ne sont tout simplement pas assez intelligents pour nous soulager de cette tâche.

Par conséquent, (1) si votre suite de tests est incomplète, il n'y a pas de moyen simple de voir cela. L'analyse de la couverture de code peut prouver que certaines lignes de code ne sont jamais exécutées, c'est-à-dire que la suite est déficiente d'une manière ou d'une autre, mais pas la gravité de cette déficience, et elle ne peut jamais prouver qu'elle est suffisante. Même avec une couverture de code à 100%, vous n'avez aucune garantie que tous les États concernésdu système sont exercés, et une couverture d'état complète est impossible pour tout système réaliste en raison du nombre combinatoire d'états qui pourraient exister. Une bonne technique pour vous assurer que votre cas de test est au moins correct pour vérifier la chose que vous voulez vérifier consiste à écrire le test, à vérifier qu'il échoue effectivement, à écrire / modifier le code, puis à vérifier qu'il passe maintenant. D'où l'engouement pour le développement piloté par les tests: il vous permet d'être certain qu'un test individuel fait la bonne chose, et si vous créez l'intégralité de votre base de code de cette manière, vous pouvez obtenir un niveau de confiance similaire même dans un grand système.

(2) Une suite de tests devient normalement insuffisante chaque fois que les exigences changent - vous n'avez pas à deviner. Si le client souhaite modifier un comportement particulier et que vos tests réussissent avant et après le changement, il est clair qu'il n'exerçait pas cette relation d'entrée / sortie particulière.

En ce qui concerne les systèmes hérités qui n'ont pas de couverture de test, ou lorsque vous ne savez pas quelle est la couverture, il n'y a aucune preuve formelle, mais (avis parental: une opinion personnelle suit!) Parlant d'expérience, il est extrêmement probable que les tests ne sont pas adéquates. Lorsque les tests sont considérés comme une activité après-coup, facultative, d'amélioration de la qualité mais pas vraiment nécessaire, ils ont tendance à être incomplets et non systématiques, car l'incitation à s'assurer que les tests suivent la base de code n'est tout simplement pas pas là.

— Kilian Foth
source