Il y a des projets où tout commence bien. Une belle stack, une équipe motivée, et un périmètre clair. Puis, un jour, une petite alerte : un bug qui revient, une régression imprévue, une incompréhension dans le code. Le constat tombe : “Mince, on a oublié les tests”.

Chez INOCO, on le sait : plus on s’y prend tard, plus on s’en mord les doigts. Mais comment remettre le sujet des tests unitaires au cœur du projet quand l’existant est bancal ? C’est précisément ce qu’on a discuté dans notre dernier café-débat, à partir d’un retour d’expérience terrain.

Le point de départ : un faux semblant de tests

Quand Quentin arrive sur un projet front, il découvre une application Angular bien modulaire, structurée autour de 20 projets… et près de 300 fichiers de tests. Sauf qu’aucun ne passe. Pourquoi ? Parce que générés automatiquement au fil de l’eau, les tests n’ont pas été maintenus. Certains fichiers ne contiennent que le strict minimum pour valider la création d’un composant, sans jamais vérifier son comportement réel.

Un besoin vital de filet de sécurité

Dans un contexte où les équipes tournent et où les nouveaux arrivent régulièrement, les tests deviennent un garde-fou essentiel. Ils permettent :

• de détecter les régressions invisibles pour un développeur qui ne connaît pas encore l’architecture,

• de fiabiliser les corrections de bugs,

• de poser un cadre structurant sur la qualité du code.

Et surtout : de rassurer. « Maintenant, je sais que si je casse quelque chose, je le verrai ».

Comment faire des tests unitaires sur un projet déjà commencé ?

Reprendre les tests un à un

Le chantier commence par un grand ménage : désactivation d’une version obsolète de Storybook, et passage en revue des tests.

Objectif : faire en sorte que tous les tests existants s’exécutent correctement, même les plus simples. Une fois cette base posée, on peut réintégrer les tests dans les PR sur GitHub, et bloquer toute tentative de merge si un test échoue.

Intégrer la démarche dans la dynamique d’équipe

Mais faire passer les tests, ce n’est pas suffisant. Il faut que l’équipe joue le jeu. Et pour ça, on met en place :

• des règles dans GitHub pour bloquer les PR si les tests échouent,

• des seuils de couverture dans Sonar, ajustables mais exigeants (80% sur le nouveau code, par exemple),

• une stratégie progressive d’ajout de tests à chaque modification ou correction.

Comme toujours, l’important, ce n’est pas d’avoir une couverture parfaite du jour au lendemain, mais d’instaurer une dynamique durable.

Anticiper plutôt que guérir

L’histoire racontée ici n’est pas isolée. Un autre collègue nous parlait récemment d’un projet back-end de 7 ans sans tests, repris après plusieurs développeurs. Résultat : impossible de toucher à un bout de code sans craindre de tout casser ailleurs. Là où Quentin est intervenu au bon moment, sur une base encore malléable, d’autres arrivent trop tard… et subissent.

En conclusion : imposer les bonnes pratiques sans rigidité

Oui, on peut configurer des blocages stricts. Mais l’important, c’est d’abord d’embarquer l’équipe. Montrer les bénéfices. Partager les cas où les tests ont évité une crise. Et créer une culture commune : un code non testé est un code instable.

Et si certains pensent que “le développeur est un peu fainéant” — alors mettons un cadre  qui l’aide à bien faire du premier coup 😉.