• # Rien de nouveau, non?

    Posté par  (site web personnel, Mastodon) . Évalué à 7 (+4/-0).

    Je crois que cet article parle juste de la loi de Goodhart. En faisant du TDD avec les yeux sur les indicateurs (la couverture de code et les 100% de tests OK), on oublie les objectis originaux de la méthode: avoir une base de test assez complète, de façon à pouvoir se lancer dans une refactorisation du code en minimisant les risques de déclencher des régressions non détectées.

    Et, bien sûr, d'avoir des tests qui sont associés aux besoins et spécifications du produit (ou, à la rigueur, du module en cours de développement), sinon ça ne sert à rien.

    • [^] # Re: Rien de nouveau, non?

      Posté par  . Évalué à 6 (+4/-0). Dernière modification le 15 mai 2026 Ă  11:14.

      Et, bien sûr, d'avoir des tests qui sont associés aux besoins et spécifications du produit (ou, à la rigueur, du module en cours de développement), sinon ça ne sert à rien.

      Ça je l'ai constaté en demandant naïvement à Claude de me créer des tests pour une appli Python que j'ai développé pour mon besoin personnel il y a une dizaine d'années. Il m'a créé plus de 1000 tests qui ont tous marché sans révéler le moindre bug !

      Ciel, avais-je fait une appli de quelques milliers de lignes sans bug ?!

      Non, bien évidemment. Même en ayant pris le soin de décrire ce que devait faire l'appli (mais de façon non exhaustive et surtout non formelle), Claude s'est principalement inspiré du code pour en déduire ce que ça devait faire et les tests ont surtout permis de vérifier que son analyse du code était ok, pas que le code faisait tout ce qu'il était censé faire pour l'utilisateur.

      Ceci dit, les tests générés par un LLM sur la seule base du code peuvent quand même être utiles si on a une application qui tourne depuis longtemps sans bug apparent et en faisant a priori tout ce qu'on attend d'elle, et qu'on veut la modifier: c'est une bonne base pour tester la non-régression.

    • [^] # Re: Rien de nouveau, non?

      Posté par  . Évalué à 5 (+2/-0).

      Dans les objectifs, il y a aussi réfléchir en amont à ce que devrait faire l'application, ou lever des lièvres pendant le développement, trucs à causer avec les utilisateurs … . Les tests écrits au préalables ne sont pas non plus supposés restés figés, si il s'avère que la specification initiale envisagée est mauvaise …

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.