Des tests qui achètent de la confiance, pas de la couverture
Un pourcentage de couverture mesure l'exécution, pas la confiance. Une suite utile se conçoit autour d'une autre question : qu'est-ce qui me permettrait de refactorer sans peur ?
- Tests
- Clean code
- TypeScript
Toutes les équipes disent valoriser les tests. Peu savent répondre à la question qui compte : quelles régressions cette suite attraperait-elle ? Une suite peut exécuter 90 % des lignes et n'attraper presque rien : vérifier que des mocks ont été appelés, snapshoter du markup que personne ne lit, tester que le framework fonctionne. La métrique monte ; la confiance, non.
Tester le comportement à la frontière
Les tests que je garde exercent une surface significative : pour cette entrée à la frontière du module, ce comportement observable en sort. Les règles métier via leur fonction publique. Un endpoint via une requête. Un générateur de slug via ses chaînes. Ces tests survivent aux refactors parce qu'ils fixent ce que le système fait, pas la façon dont il le fait aujourd'hui.
Les tests couplés aux détails internes font l'inverse : chaque refactor les casse, donc les refactors s'arrêtent. Exactement à rebours du but. La suite existe pour rendre le changement sûr, et elle finit par le taxer.
Laisser le système de types prendre sa part
En TypeScript strict, des catégories entières de tests deviennent redondantes : nullabilité, mauvaises formes, champs manquants aux frontières validées par un schéma. Laissez le compilateur et le schéma tenir cette ligne, et investissez l'effort de test là où les types ne portent pas : la logique, les cas limites, l'intégration entre parties réelles.
Le test du refactor
Mon critère d'acceptation pour une suite est simple : pourrais-je restructurer l'intérieur d'un module et faire confiance à un run vert ? Si oui, les tests sont un actif. Si un refactor implique de réécrire les tests aussi, ils ne testaient pas un comportement. Ils étaient une seconde copie de l'implémentation, et toute copie est un passif.