LES TESTS SONT DU CODE

LA SOUPLESSE GAGNÉE

L'Extreme-Programming est une sacrée aide. Grâce au TDD, au remaniement et à la conception simple, nous arrivons à mettre au point des logiciels ayant une architecture extensible. Nous ajoutons des incréments de fonctionnalité au fil des itérations. Les tests de recette et les tests développeur sont un tuteur qui aident le logiciel à pousser et un filet de sécurité contre les régressions. Ils permettent au logiciel de conserver sa souplesse, celle du SOFTware .

Nous pratiquons le TDD et le test-first. La couverture du code par les tests est intégrale. De plus, ayant les contraintes de sûreté de fonctionnement du logiciel critique, nous ne lésinons pas sur les cas de tests.

D'ailleurs, en démo nous nous livrons à un petit exercice. Nous proposons au client d'introduire un défaut dans la base de code et nous lui montrons que la suite de tests détecte sa modification.

Depuis plusieurs projets, nous constatons que nous avons plus de deux fois plus de lignes de code de test que de lignes de code de production. Étant donné qu'il faut vérifier de nombreux scénarios, le code des tests est souvent assez répétitif.

Vous voyez où je veux en venir?

LA SOUPLESSE PERDUE

Cette masse de tests est là en partie pour conserver la souplesse du logiciel testé. Elle est un tuteur construit autour de l'application. Mais si nous ne faisons pas très attention, cette masse de tests devient inflexible.

Tous ces cas de tests si ressemblants sont autant de mauvaises occasions de dupliquer du code. Tous ces mocks et tous ces stubs aux comportements légèrement différents doivent tous évoluer si leur interface de base est amenée à changer. Pour modifier une ligne de code de production nous en arrivons à devoir changer plus de 10 lignes de code de test. Le code des tests tend naturellement à devenir une masse pénible à faire évoluer. Les tests deviennent inflexibles. Le tuteur est devenu un massif baobab. Le logiciel perd alors sa souplesse d'évolution parce que les tests sont devenus inflexibles. Avec de bonnes intentions nous avons rendu l'application inerte. Elle a perdue sa souplesse parce que l'échafaudage qui l'enrobe est devenu un gros sac de nœuds.

LA SOUPLESSE GAGNÉE (BIS)

Heureusement, ce constat n'est pas une fatalité. Nous avons de la chance car les tests sont aussi du code. Nous devons donc porter au code des tests le même soin qu'au code de production. Les standards de codage s'appliquent au code de production et au code des tests. Nous devons systématiquement remanier le code des tests pour en éliminer les duplications, en réduire le volume et le rendre clair et expressif.
Il existe une architecture des tests. Si une classe hérite d'une autre alors son test unitaire hérite du test unitaire de la super-classe. Ainsi, nous rejouons des tests hérités sur une instance fille. Ceci nous permet de vérifier le si puissant Principe de Substitution de Liskov.
En remaniant les tests, nous devons faire bien attention à ne pas les faire régresser. Ceci est d'autant plus délicat que le code des tests est écrit sans tests! Quoique nous pouvons assimiler le code testé au test des tests (vous me suivez toujours?). Modifiez un test et vous aurez peut-être la chance de le voir échouer s'il n'est plus en cohérence avec le code testé. Ceci ne marche malheureusement pas si la modification du test l'a rendu plus permissif ...

En tout cas, ce qui est génial, c'est que tester c'est coder!