Finding Failure Causes through Automated Testing

✒ Enzo SandrĂ© · 📆 03/12/2024 · đŸ§Ș Tests

🐛 Une rĂ©vision fonctionne, alors qu’une autre bugge. C’est presque une routine. Le dĂ©veloppeur doit alors rechercher la cause racine du bug et la corriger. L’usage de tests dans ce processus est ancien, bien qu’il ne soit apparu dans la littĂ©rature scientifique qu’autour des annĂ©es 2000. L’idĂ©e est simple : reproduire le bug dans un cas de test pour l’empĂȘcher de revenir. C’est le defect testing. HĂ©las, cette technique n’aide pas Ă  trouver la cause racine, ce qui reprĂ©sente 95% du temps de debug.

đŸ§Ș Deux chercheurs allemands proposent d’utiliser les tests afin de repĂ©rer la cause racine. Il faut pour cela deux rĂ©visions sĂ©parĂ©es par un delta. Dans la premiĂšre, le test de dĂ©faut fonctionne, dans l’autre celui-ci est cassĂ©. L’étape suivante est de trouver le scĂ©nario minimal dans lequel le bug se produit, en diminuant la quantitĂ© de changements du delta. Cette Ă©tape n’est pas obligatoire, mais rĂ©duit largement la quantitĂ© de calculs nĂ©cessaires ensuite. La derniĂšre Ă©tape consiste Ă  muter le code afin de trouver le plus petit jeu de changements provoquant le bug, donc faisant passer au rouge le test de dĂ©faut. Cette Ă©tape est extrĂȘmement lourde en calculs, car le nombre de mutants Ă  gĂ©nĂ©rer et tester est immense.

đŸ—œïž Cette technique n’est pas utilisĂ©e en l’état par les praticiens, Ă  ma connaissance. Elle pourrait cependant ĂȘtre Ă  l’origine du shrinking utilisĂ© en property-based testing.

SOURCE

Cleve, Holger and Andreas Zeller. “Finding Failure Causes through Automated Testing.” arXiv: Software Engineering (2000) DOI:10.48550/arXiv.cs/0012009

Enzo Sandré


📄 Lien public DOIs: 10.48550/arXiv.cs/0012009