L'article est basé sur une publication sur la chaîne de télégramme Cross Join .
Avant de parler de cette approche, je vais d'abord expliquer en quelques mots ce qu'est le test de mutation en général. Pour ceux qui ne sont pas au courant.
Test de mutation
Lorsque vous écrivez des tests, TDD ou non, même avec une couverture formelle à 100%, vous ne serez jamais sûr que tout est réellement testé dans le code. Par exemple, il est possible de faire une erreur ringarde en appelant assert dans le test lui-même.
assertEquals($a, $a);
Et si même pendant les tests, il était possible d'en atteindre si, ce n'est pas un fait que toutes les conditions de celui-ci sont correctement vérifiées.
Pour vous assurer que les tests sont vraiment des tests, il existe un moyen: introduire vous-même des bogues dans le code et voir si les tests en sortent. Si les tests sont encore verts avec un bug évident, alors tout n'a pas été testé.
Par exemple, vous avez changé le plus en moins, ou ajouté «non» à la condition et voyez si les tests ont réagi. Cette approche est appelée "Mutation Testing".
Cela se fait généralement dans des domaines très critiques de la programmation, où les erreurs ne sont généralement pas autorisées. Par exemple, un logiciel mobile ou un logiciel médical.
Bien sûr, dans la construction de rover, tout se fait automatiquement: un outil spécial défigure votre programme et cherche à voir si les tests ont échoué.
, , , , , . : AST, .
Mutation Driven Development
mutation driven development. TDD, .
- , ( )
- ( if). , , MDD (?) , 100% overage TDD.
, CI, , , MDD .
, , . mutation driven testing , . , .. , , , , , ., 95% , - -. , .
Nous discuterons bien sûr du développement axé sur les mutations dans l'une des prochaines ventes de zinc , n'oubliez pas de vous abonner au podcast