
Envoyé par
Matthieu Vergne
TL;DR: Je ne vois pas le rapport avec les LLM.
La couverture de test n'a jamais été une métrique pertinente de qualité du code. Il s'agit d'un indicateur bas de gamme de la qualité des tests : ce qui est rouge n'est pas couvert par des tests, donc soit c'est du code mort à enleverMerci pour cette réaction constructive, @Matthieu Vergne. Vous avez raison sur un point : ces pratiques ne sont pas nouvelles. Je concède volontiers que tout cela était vrai avant les LLM.
Cependant, je pense que c'est justement là le problème : les équipes découvrent trop tard que ces pratiques fondamentales manquent, précisément dans le contexte LLM.
La différence avec les LLM, c'est l'ampleur et la vitesse :
1. **Hallucinations déguisées** : Un LLM génère du code qui paraît cohérent syntaxiquement mais viole les exigences métier. Les tests unitaires classiques passent. La "mutation testing" que vous mentionnez nécessite une infrastructure qu'aucune équipe n'a quand elle intègre l'IA.
2. **Impossible de faire du code review manuel** : Avec un dev classique, vous pouvez relire. Avec un LLM générant 10x plus de code, c'est humainement infaisable. Il faut donc que les tests soient robustes *dès le départ*.
3. **La couverture devient critique, pas pertinente** : D'accord, ce n'est qu'un indicateur. Mais dans un flux LLM, c'est souvent l'*unique* filet de sécurité avant la prod.
Votre point sur la "cohérence métier" est exactement ce qui manque dans les déploiements IA que j'observe. C'est mon argument exact., soit il manque de test. C'est la seule chose intéressante qu'enseigne la couverture. Quand tout est vert, tu n'as plus aucune info à tirer de cette métrique, puisqu'un code vert veut seulement dire qu'il est exécuté lors du test, pas vérifié par le test.
Quand la couverture est à 100%, on peut passer au niveau suivant : s'assurer que le code ne régresse pas lors de futurs changements. Si on change le code, un test doit casser. Pour mesurer ça, tu peux utiliser du mutation testing : ça change le code (mutation) et refait tourner les tests pour confirmer que tu en as au moins un qui casse. Si rien ne casse, manque de test. Ça coûte bien plus cher à mesurer que la couverture de test (on réexécute la suite de test pour chaque changement) mais ce n'est encore une fois qu'une mesure de la qualité des tests, donc pas besoin de l'exécuter à chaque fois. L'exécuter régulièrement suffit (idéalement lors de la validation d'une PR, pour confirmer que les changements apportés sont correctement testés).
Mais tous ces tests ne valent rien s'ils ne valident pas le code. C'est là qu'intervient ta "cohérence métier" : il faut s'assurer que les exigences (cahier des charges) sont représentées dans les tests. Si un test ne se rattache à aucune exigence, c'est que ce test contraint le code sans raison évidente, et sera donc plus une épine dans le pied en cas de refacto qu'une sécurité contre la régression. Si un bout de code est remis en cause via mutation testing ou manque de couverture, soit c'est une exigence implicite (à expliciter avec du test), soit c'est du code inutile (à retirer), soit c'est un détail d'implémentation (changeable à tout moment pour s'adapter au contexte, donc ne devant pas être testé pour ne pas bloquer ces changements). À confirmer avec le PO, notamment pour expliciter l'exigence le cas échéant.
Et quand tu fais ça, la stabilité comportementale est garantie par l'exécution des tests et la gestion des cas limite aussi. En fait, ces deux notions sont la base du test automatisé.
L'idéal théorique étant un couverture de 100% (tout est exécuté), un mutation testing de 100% (tout est testé), et une traçabilité de 100% (uniquement des tests explicitement liés à des exigences). La pratique est toute autre.
Tout ça, c'était déjà vrai avant les LLM.
Partager