Une bonne couverture de tests doit s’accompagner d’une fragilité des tests

Une bonne couverture de code par les tests est primordiale. En même temps, un taux de couverture élevé ne signifie pas grand chose. ce que je vais appeler la fragilité des tests est un élément très important.

Par exemple : Ca n’est pas parcequ’un test couvre une partie de mon code que cette partie est testée. Imaginer un test sans asser. Ce test participe à la couverture des tests mais pas à leur qualité. En effet, s’il n’y a pas d’assert, le test a toutes les chances de toujours passer. Un test pour être efficace doit être plutôt fragile. C’est à dire qu’il doit casser à la moindre modification du fonctionnel.

Certains outils comme jester.sourceforge.net cherchent à mettre en évidence les tests trop résistants au changement. L’idée est que si je touche le code de façon intelligente, au moins un des tests devrait casser.

Une autre méthode plus statique serait de pondérer la couverture du code par les tests en fonction du nombre d’assert par test et de leur type : un assert.isNotNull() est moins fragile qu’un assert.equals(). Il participe donc moins bien à l’effort de test.

Connaissez-vous des outils de ce type ?

One thought on “Une bonne couverture de tests doit s’accompagner d’une fragilité des tests”

  1. Tu restes vague sur “la couverture de test”, on devrait plus regarder la couverture de branche que la couverture de ligne. Mais c’est tellement plus difficile à faire évoluer.

    Carrement bon l’idée de pondérer en fonction des types d’assert.
    assertNotNull() +1
    assertEquals() +10
    assertTrue(true) -50…

    Je crois qu’agitator (d’agitar software) donne la couverture de code mais aussi donne le nb d’assert (non pondéré).

    Bon maintenant si tout le monde faisait des tests déjà…

Comments are closed.