Manual testing, c'est déja ca ;-) Automated Unit Testing, c'est un bon début Integration Testing, un cran plus haut niveau et après ?

Lors de ces procédures de tests il est (trop) souvent mis en avant qu'une des metrics reine est le code-coverage. Cependant, c'est plutot le nombre d'assertions qui prime au final, le coverage étant surtout le nombre de lignes ayant été exécutées durant les tests. En poussant à l'extrême, on peut facilement imaginer un code 100% "couvert" par les tests, mais avec 0 assertion, ces tests "blancs" (passeront donc quelques soient les entrées) mais à fort coverage, semble avoir une valeur ajoutée.

Une deuxième hantise du testeur est de "Ne jamais faire confiance à 1 test que l'on a jamais vu FAIL".

C'est là que le Mutation Testing entre en scene.

Des frameworks existent (en PHP il y a Infection https://infection.github.io ) qui vont prendre les 2 "artifacts" existants déjà dans votre projet (le code source et vos tests) et va tout simplement

1. modifier votre code (1 seule modification ! ceci étant 1 mutation)
2. faire tourner les tests
3. s'attendre à ce que vos tests "détectent" cette mutation en reportant au moins 1 test FAIL.
4. répéter avec 1 nouvelle mutation

Une approche simple, mais coûteuse sur le temps de build, d'avoir un bon retour sur la qualité et valeur réelle de vos tests, et ce avec un cout d'entrée vraiment faible.

Une approche où finalement le but est d'avoir des tests qui FAIL ! mais aussi surtout pour le plaisir de tuer des mutants ;-)

Comments

Comments are closed.

Merci, j'avais déjà vu des confs sur le mutation testing, mais là j'ai vraiment compris l'interêt de tester nos tests. Je vais essayer de le mettre en place dans des projets.

Alex Rock at 17:21 on 19 Jun 2020

Clairement utile ! Le test qui teste les tests, c'est vraiment un bon plan :)

Xavier Besson at 10:46 on 24 Jun 2020

Très utile et cette conférence m'a permis de bien comprendre une mise en place de cet outil