Comment les gens entretiennent-ils leur suite de tests?

En particulier, je suis curieux des aspects suivants:

1. 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?

2. 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?

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.

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à.