shop-cart

Vous lisez actuellement: La couverture des tests est morte, longue vie au test de mutation !

La couverture des tests est morte, longue vie au test de mutation !

Dans l’industrie d’aujourd’hui, avoir un bon produit peut ne pas suffire. La concurrence est imminente et l’un des principaux avantages des leaders du marché est leur capacité à agir rapidement sans rien casser.

Les entreprises sont de plus en plus obsédées par la qualité. Comme nous le savons tous, nous sommes très gâtés en tant qu’utilisateur final. Combien d’entre vous ont pensé et même prononcé à haute voix la phrase suivante: «Je déteste cet OUTIL_GRATUIT ! Il n’a pas réussi à charger une fois lorsque j’en avais besoin. » En conséquence, de nombreuses entreprises ont placé la qualité des produits sur un piédestal et les considèrent comme leur Saint-Graal.

En recherchant simplement sur le Web comment garantir la qualité dans le cadre d’un cycle d’intégration continue / déploiement continu (CI / CD), on comprend aisément que les tests automatisés sont indispensables et que les tests unitaires en sont l’une des pierres angulaires.

Mais “Combien de tests ?”, Pourrait-on demander à la zone de saisie de son moteur de recherche préféré. Malheureusement, la réponse ici est vague.

En explorant le World Wide Web, vous voyez que la couverture de code est l’index clé. En fonction de votre type de code (fonctionnalité, logique, etc.), vous pouvez définir un pourcentage de couverture de code aléatoire que vous souhaitez appliquer. En essayant de réaliser cela, vous pouvez voir que, dans la plupart des cas, 100% est presque impossible. Alors que 80% est meilleur pour votre code, 100 est-il vraiment meilleur que 80? Si vous ajoutez plus de tests, cela signifie-t-il que votre suite de tests est plus puissante? Ou s’agit-il simplement d’une surcharge exagérée lors de l’ajout de fonctionnalités?

La recherche d’un indice de couverture aléatoire présente certains pièges. De par mon expérience personnelle, en tant que développeur assidu, j’ai parfois l’impression d’investir trop de temps dans la création et la modification de tests au cours de toutes les phases de développement et de maintenance. D’autre part, un ami développeur roublard et paresseux m’a dit un jour qu’il avait entendu dire que certains développeurs ajoutaient des tests pour améliorer la couverture, mais que ces tests ne couvraient pas entièrement la fonctionnalité – OMG !!!

Améliorer la couverture est facile – il suffit d’appeler la fonction ou de charger l’objet, d’utiliser différentes entrées – c’est fait! Et cela n’arrive pas toujours exprès. Parfois, nous ne pensions simplement pas à tous les cas extrêmes de l’unité testée, peut-être parce que nous étions tellement concentrés sur l’élimination des lignes rouges du code non couvert.

Arrêtez de tuer les lignes rouges – Tuez les mutants

Une excellente solution consiste à ne plus être obsédé par la couverture du code de test et à l’envisager avec un certain recul. Je vous exhorte à promouvoir le test de mutation comme indice clé de la force d’une suite de tests.

Le test de mutation consiste à modifier le code – une petite partie à la fois – créant des mutants et à l’exécution répétée de la suite de tests unitaires. Si les tests réussissent toujours – c’est-à-dire qu’ils n’ont pas été en mesure d’identifier le mutant (ce qui pourrait représenter un mauvais comportement) -, nous pouvons en conclure qu’ils sont moins forts et inversement.

Par exemple, supposons que j’ai besoin d’écrire une fonction qui vérifie si mon réacteur nucléaire doit être refroidi ou s’il subira une fusion nucléaire (ce n’est pas bon) – cela serait vrai si la température était supérieure à 1000 ° C. La simple implémentation de la fonction et des tests ressemblerait à ceci:

function isDangerous(temp) {
  if (temp > 1000) {
    return true; //run away now!
  } else {
    return false; //it’s a very nice…
  }
}

test(“test isDangerous”) {
  expect(isDangerous(500)).toBeFalsy();
  expect(isDangerous(2000)).toBeTruthy();
}

Les tests sont réussis et la couverture de test serait de 100% – yay ! Cependant, comme nous le savons, la couverture de codes n’est pas le meilleur indicateur de la force et de la minutie des tests.

Si nous devions exécuter un outil de test de mutation, il exécuterait ces tests avec une simple mutation consistant à changer ‘>’ en ‘> =’ (une mutation courante) et espérerait que mes tests échoueraient (puisqu’un éventuel changement de la fonctionnalité a été faite). Cela a révélé une faiblesse dans mes tests – j’ai oublié de vérifier et de m’assurer que je gère correctement le numéro 1000. Cela signifie que mes tests peuvent être bons, ils ne sont toujours pas suffisamment approfondis. Il est facile d’y remédier, il suffit d’ajouter:

expect(isDangerous(1000)).toBeFalsy();

Cette méthodologie de test peut nous fournir une bien meilleure réponse à la question de savoir «A quel point nos test sont bon / forts?

Un excellent outil pour cela est le stryker-mutator, qui est simple à exécuter dans la CLI, supporte les principaux frameworks de test (karma, jest, jasmine, etc.) et dont le résultat est un outil solide pour améliorer la résistance de vos tests et la résilience logicielle.

Vous devez en toute circonstance vous considérer comme obsédés par la qualité que vous fournissez à vos clients. Par conséquent, vous avez besoin de transparence sur la qualité réelle de la résilience de vos systèmes et sur la qualité de vos tests. Les tests de mutation nous en fournissent une dans de nombreux projets.

Crédits

Vous pouvez retrouver l’article original de Yotam Kadishay ici :
https://medium.com/appsflyer/tests-coverage-is-dead-long-live-mutation-testing-7fd61020330e

A story about

, ,

,

Avec

195

Vues


Écrit par

Thomas Paoli

Thomas est développeur front et devops, c’est le couteau suisse de blueanchor. Il se reconvertit au technos web depuis 6 mois et apprend à manier le framework Angular. Fan d’open source et d’administration système, il gère les serveurs et les outils de l’équipe.


Afficher la conversation (0)

Recommander cette page

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

0 People Replies to “La couverture des tests est morte, longue vie au test de mutation !”