Pourquoi tes tests unitaires ne servent à rien (et comment y remédier)

“Les tests passent.”
“Alors c’est bon.”
Non. Pas forcément.

On a tous connu cette satisfaction : le build est vert, les tests unitaires passent, et la pipeline DevOps affiche fièrement ✔️ All tests successful.
Et pourtant, quelques jours plus tard, un bug remonte.
Un vrai. En production.
Et tu te dis : “Mais comment c’est possible, tout était testé !”

Le problème ne vient pas toujours de ton code.
Souvent, il vient de toi.
Plus précisément, de ton cerveau — et de ses biais cognitifs.

Tes tests ne testent pas ce que tu crois

En théorie, un test unitaire vérifie le comportement d’un morceau de code.
En pratique, il reflète souvent ce que tu penses que ton code fait.

Quand tu écris un test après coup, tu n’évalues pas ton programme, tu valides ton interprétation du programme.
Et c’est là que les biais s’invitent.

Le biais de confirmation : le plus dangereux

C’est le grand classique.
Tu veux prouver que ton code marche — pas qu’il est faux.

Exemple concret en C# :

[Test]
public void ShouldAddTwoNumbersCorrectly()
{
    var calc = new Calculator();
    var result = calc.Add(2, 3);
    Assert.AreEqual(5, result);
}

Ce test passe.
Mais il ne teste rien de critique : pas de bornes, pas d’erreurs, pas de cas anormal.

En réalité, il confirme ta croyance que la méthode Add fonctionne, sans jamais la remettre en cause.

Comment y remédier :

• Écris tes tests avant le code (TDD).
• Ajoute des tests négatifs : overflow, valeurs nulles, cas extrêmes.
• Cherche à faire échouer ton code avant de le valider.

Le biais d’ancrage : ton code influence ton test

Tu écris ton code, puis ton test.
Le cerveau “s’ancre” sur ce qu’il vient de voir.
Résultat : ton test reproduit la logique interne au lieu de la vérifier.

public int Add(int a, int b) => a + b;

[Test]
public void Add_ReturnsSumOfNumbers()
{
    var calc = new Calculator();
    Assert.AreEqual(5, calc.Add(2, 3));
}

Ton test et ton code disent exactement la même chose.
Tu as testé la syntaxe, pas le comportement.

Comment y remédier :

• Écris le test avant d’implémenter.
• Conçois ton test comme une boîte noire : ne regarde pas le code, regarde son contrat.
• Fais des revues croisées : une autre personne écrit les tests.

Le biais du survivant : tu testes ce que tu connais déjà

“Ce bug ne s’est jamais produit, inutile de tester ça.”

Faux.
Les bugs les plus dangereux sont justement ceux qu’on n’a jamais vus.

Exemple :

calc.Add(1, 2);
calc.Add(10, 20);

Mais jamais :

calc.Add(int.MaxValue, 1);

Comment y remédier :

• Utilise des tests property-based (ex : FsCheck) pour explorer des cas inattendus.
• Inspire-toi des logs de production pour trouver des scénarios réels.
• Demande-toi : “Qu’est-ce qui pourrait casser ce code ?”

Le biais d’auto-complaisance : “Mes tests passent, je suis bon”

C’est le biais le plus flatteur.
On aime croire que des tests qui passent = un code robuste.
Mais un test peut passer même s’il ne sert à rien.

Comment y remédier :

• Vérifie ta couverture de code, mais sans t’y fier aveuglément.
• Utilise du mutation testing (par ex. Stryker.NET) : il injecte volontairement des erreurs pour voir si tes tests les détectent.
• Si un test passe alors qu’il devrait échouer… c’est qu’il ne testait rien.

Le biais du statu quo : “On a toujours testé comme ça”

Tu continues à copier-coller les mêmes patterns de test depuis 5 ans.
Tu te méfies des outils modernes (AutoFixture, FluentAssertions, Bogus…).
Et tu t’enfermes dans une zone de confort technique.

Comment y remédier :

• Refactore aussi tes tests.
• Essaie des outils qui simplifient :

[Theory]
[InlineData(2, 3, 5)]
[InlineData(-1, 1, 0)]
public void Add_ShouldWork(int a, int b, int expected)
    => new Calculator().Add(a, b).Should().Be(expected);

Remets régulièrement en question ta manière de tester, comme ton code de prod.

Le biais d’autorité : “Si le lead le dit, c’est vrai”

Tu appliques les bonnes pratiques de ton équipe sans les remettre en question.
Parfois, elles sont obsolètes.
Parfois, elles ne s’appliquent pas à ton contexte.

Comment y remédier :

• Challenge les dogmes : mock ou pas mock ? base réelle ou mémoire ?
• Appuie-toi sur des métriques, pas sur des opinions.
• Fait des revues de test collectives — c’est là que la qualité se construit.

Tester, c’est douter

Les tests unitaires ne servent à rien…
si tu les écris avec les mêmes biais que ton code.

Mais si tu acceptes de douter, de casser, de remettre en question —
alors ils deviennent le meilleur reflet de ta rigueur technique.

Et dans l’idéal, celui qui teste ne devrait pas être celui qui code :
cela permet de confronter deux visions, deux raisonnements, deux angles d’erreur possibles.
C’est ainsi qu’on débusque les biais, qu’on renforce la qualité,
et qu’on transforme un test en véritable garde-fou.

Tester, c’est douter.
Et c’est précisément ce doute qui fait la différence entre un code qui fonctionne
et un code qui résiste.