Ajouter un test unitaire pour chaque nouveau bogue

Dans mon travail, tous les développeurs qui résolvent un bogue doivent ajouter un nouveau test unitaire qui avertit de ce type de bogue (le cas échéant, il se reproduit). Si un test unitaire n'est pas possible (par exemple, un problème de conception de page Web), le service d'assurance qualité doit créer un scénario de test pour le vérifier manuellement.

L'idée sous-jacente est que si un défaut n'a pas été détecté avant la sortie du produit, c'est qu'il n'y a pas de test unitaire approprié pour le détecter. Le développeur doit donc l'ajouter.

La question qui se pose est la suivante: cette méthodologie est-elle commune à toutes les méthodes de développement logiciel? Cette technique a un nom? J'aimerais en apprendre plus à ce sujet, mais j'ai besoin de quelques informations pour commencer.

C'est assez commun. Nous l'utilisons dans notre équipe. Pour chaque défaut de production, le développeur doit ajouter une note sur la cause première du problème, ajouter un test unitaire en échec et ajouter une analyse d'impact de test avant que le ticket ne puisse passer à l'état dev pour enregistrer le code.

Le test unitaire défaillant doit réussir avant que nous puissions passer le code à la production.

Je ne pense pas que cela porte un nom spécifique, à l'exception de ce "test de régression" général. Ceci est très utile et nous avons commencé à observer une amélioration de la qualité du produit après avoir suivi ce processus.

Absolument!

Si vous pouvez convenir que les tests unitaires sont une bonne chose, vous réaliserez alors que s’il ya un bogue, il manque un test unitaire couvrant ce chemin de code.

Donc, ce qui devrait arriver, c’est que vous écrivez un test unitaire qui montre que le bogue existe, corrigez le bogue réel, puis le test unitaire passera.

Si vous n'avez aucun test unitaire, cela peut être un bon moyen de commencer à introduire des tests unitaires dans un projet.

La technique est un développement piloté par des tests. Il ne s'agit pas vraiment de pouvoir repérer un bogue similaire la prochaine fois, bien que la suite de tests répétables soit toujours utile. Le fait est que vous pouvez démontrer que vous avez isolé ce qui ne va pas avec le code, vous avez prouvé que c'est faux, vous l'avez corrigé, que le correctif est correct.

Il y a une citation que je ne me souviens pas ou que je ne trouve pas, mais qui dit en gros: "Chaque bogue est un test qui n'a pas encore été écrit."

Essayer de le vendre comme test de régression est une bataille perdue, à mon humble avis. Etant donné que rarement ces problèmes attrapent un bogue répété, la plupart des développeurs diront simplement: "Pourquoi vous embêter, alors que je peux simplement le réparer?"

Cette technique est assez courante et, à mon avis, son meilleur nom est «Test par défaut» (je l’ai moi-même inventé et puis j’ai trouvé celle-ci décrite sous ce nom il y a longtemps ).

Certaines personnes appellent parfois ces tests des «tests de régression», mais j’ai personnellement du mal à justifier ce nom. Une définition un peu plus répandue (et qui a sans doute plus de sens pour ce nom) de «test de régression» est «exécuter des tests après toute modification du code afin de s’assurer que vous n’avez pas introduit de régression» et votre CI. qui teste chaque branche sur push au référentiel le satisfait.