Mutation testing

Archi & techno

Mutation Testing, un pas de plus vers la perfection

Posté le par Nicolas de Nayer

Mutation Testing Il n'est plus à prouver l'utilité des tests unitaires. Ils sont essentiels dans la conception d'une application de qualité. Mais, savons-nous quantifier leur pertinence, leur qualité ? Un indicateur de couverture du code par les tests à 100%, ne signifie pas du code 100% testé. Cet indicateur ne détermine que  grossièrement le pourcentage de code exécuté lors du passage des tests unitaires, pas plus. Voici une technique qui vous permettra d’accorder plus de confiance à vos tests. Le processus de cette technique se déroule en deux grandes étapes…

Lire la suite
Méthode

Avez vous confiance en vos tests?

Posté le par Olivier Mallassi

Dans un précédent post, j'avais déjà évoqué l'insuffisance de l'indicateur "couverture de test" à lui seul pour garantir la détection de régressions. Pour résumer, un autre indicateur permettant de répondre aux questions "mes tests me protègent-ils contre d'éventuelles régressions?" ou formuler autrement "Quel est le niveau de confiance que j'ai dans mes tests?" doit être trouvé.

Deux idées existent. La méthode plus simple consiste à compter le nombre d'assertions réalisées: efficace et simple à mettre en oeuvre puisque cette solution repose sur un simple grep (comme si grep était simple...).
L'autre méthode repose sur le principe suivant:

Le code de test "valide" le code métier. le code métier peut valider le code de test...

Alors concrètement comment faire?! comment l'implémenter? Comme j'avais envie de coder, voilà "l'histoire" d'un POC visant à valider les principes précédemment énoncés.

Lire la suite
Archi & techno

De l’insuffisance de la couverture de tests

Posté le par Olivier Mallassi

Les besoins en terme de qualité de code amènent de plus en plus de projets à s'intéresser et à coder des Tests Unitaires. Et comme appréhender le logiciel en cours de production est complexe, des indicateurs dits "de couverture de tests" sont utilisés en complément.
Loin de moi l'idée de remettre en cause cet indicateur représentant le pourcentage de code métier exécuté par les tests. Il présente plusieurs intérêts:

  • fournir une valeur quantitative représentant la part de logiciel testé
  • fournir une visualisation (sous forme de rapport html maven ou autre) du code exécuté et surtout du code non exécuté. J'y vois là le double avantage :
  • de mieux maitriser le risque. Le code non testé est connu.
  • de permettre d'améliorer le test lui-même. En effet, du code peut ne pas être testé simplement parce qu'un cas un peu particulier a été omis et visualiser ces portions oubliées du code aide à affiner les tests. D'aucuns diront que si on fait du TDD ("Test Driven Development"), le code non testé est inutile et n'aurait donc pas du être écrit. Je peux les rejoindre dans cette approche extrême. Après, il y a la réalité des projets et du test aujourd'hui...
Reste que cet indicateur de "couverture de test" se contente de "voir" le code exécuté. That's all et ca n'est peut-être pas suffisant.

Lire la suite