Idée principale

Un assistant à qui l'on demande des tests une fois la fonctionnalité écrite produit des tests qui passent. C'est attendu : il les dérive de ce qu'il vient d'écrire. Ils vérifient que la fonction appelée avec tel argument renvoie ce qu'elle renvoie déjà, que le composant affiche ce qu'il affiche déjà. Si l'implémentation a mal compris le besoin, les tests entérinent ce malentendu et le protègent contre toute correction future.

L'effet visible est inverse de l'effet réel. Le dépôt affiche des centaines de tests verts, la suite tourne à chaque modification, et le produit paraît sécurisé — alors que rien dans ce dispositif n'a jamais confronté le code au comportement attendu par le métier.

C'est ce qui distingue une couverture d'une stratégie de test : la première mesure combien de code est traversé, la seconde décide quels comportements doivent rester vrais, à quel niveau les vérifier, et quels risques doivent être couverts.

Pourquoi c'est important

Cela empêche de lire la présence de tests comme une preuve. Sur un code généré, le nombre de tests est le chiffre le plus facile à obtenir et le moins informatif : il faut savoir d'où ils viennent — d'une intention formulée avant, ou d'une implémentation relue après.

Cela explique aussi pourquoi le sujet est difficile pour un profil produit. Il n'a pas forcément de pratique du développement piloté par les tests, ne distingue pas toujours test unitaire, test d'intégration et test de bout en bout, et n'a jamais eu à formuler une règle métier sous forme de vérification — donc il n'a aucun moyen de repérer que ce qui lui est rendu est un miroir.

Nuances et limites

Un test écrit après le code n'est pas sans valeur : il protège des régressions, et c'est déjà beaucoup sur un code qu'on ne relit pas. Ce qu'il ne fait pas est établir que le comportement était le bon.

Et l'inversion de l'ordre ne suffit pas non plus : un test écrit avant, mais par celui qui a mal compris le besoin, échoue exactement de la même façon.

Questions ouvertes

• Comment quelqu'un qui n'a jamais pratiqué le test peut-il exprimer une intention métier sous une forme vérifiable, sans réapprendre d'abord le vocabulaire du test ?