← Retour au blog

Tes 252 tests au vert ne te protègent pas (et c'est terrifiant)

On a tous ce réflexe de développeur : "Si mes tests passent, mon code est clean." C'est une illusion totale qui mène droit au mur, comme l'a découvert Albert Alov avec son outil d'observabilité. Spoiler : avoir un CI au vert ne garantit absolument pas que ton outil fait réellement le job.

Quand ton code est "parfait" mais inutile

Albert a passé un sprint complet à auditer son code. Résultat : 44 bugs corrigés, 252 tests unitaires au vert, une version 2.4.4 bien propre sur le papier. Tout était nickel, sauf un petit détail dans sa configuration OpenTelemetry : `spanProcessors: []`.

Une ligne anodine, presque invisible, qui a littéralement réduit son outil au silence. Zéro trace exportée, jamais. Ses 252 tests ne testaient pas le comportement réel du logiciel en production, ils testaient juste des composants isolés qui, techniquement, "fonctionnaient" dans le vide. C'est le piège classique du vibecoding : on passe trop de temps à perfectionner les rouages et on oublie de vérifier si la machine produit du jus.

Pourquoi tes tests t'endorment

C’est là que le bât blesse. On se sent intelligent quand on ajoute des tests, mais on crée souvent une fausse sécurité. Si tu testes uniquement la syntaxe ou la logique interne sans tester le flux réel de bout en bout, tu construis un château de cartes.

En tant que vibecoder, on aime aller vite, créer des fonctionnalités et voir les commits s'accumuler. Mais sans un test "utilisateur" qui vérifie si la donnée arrive réellement à bon port, tu ne fais que jouer aux LEGO. Ton audit de code ne verra jamais cette erreur de configuration, car pour l'ordinateur, le code est valide. Il est simplement… inutile. Ne confonds jamais "code qui compile" avec "produit qui fonctionne".

À retenir

  • Le vert n'est pas une vérité : Un CI au vert, c'est juste la preuve que tes tests ne sont pas cassés, pas que ton app fonctionne.
  • Teste le comportement, pas le code : Si ton test ne vérifie pas le résultat final attendu par l'utilisateur, c'est du bruit.
  • La config, c'est du code : Une erreur de configuration est un bug, traite-la avec autant de sérieux qu'une fonction critique.
  • Sort de ta bulle : Lance ton outil, utilise-le comme un vrai humain. Si tu ne vois pas les logs bouger en temps réel, tes tests sont juste là pour te rassurer.