đ 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