Tests unitaires avec Claude Code et Codex : construire un workflow fiable en équipe

La génération de tests unitaires par IA devient utile lorsque l'équipe vérifie que les tests peuvent réellement détecter une erreur. Claude Code et Codex peuvent proposer des scénarios et des assertions, mais un test qui passe peut reproduire le même défaut que l'implémentation. Le workflow doit donc partir d'une règle métier indépendante du code.

Dans une ESN, la réussite se mesure à la confiance apportée à la livraison : comportement attendu explicite, cas limites couverts et résultat reproductible en intégration continue. Le nombre de tests créés n'est pas un objectif suffisant.

Guide technique préparé avec assistance IA le 17 septembre 2026. L'exemple est pédagogique, sans données client. Il doit être adapté à votre environnement et ne démontre pas la qualité d'une application entière. Illustration générée par IA.

Commencer par le contrat, pas par le fichier à couvrir

Avant de demander des tests, écrivez les entrées valides, les sorties attendues et la gestion des erreurs. Si une règle est ambiguë, le responsable métier tranche. L'agent ne doit pas déduire le comportement souhaité uniquement à partir de l'implémentation existante.

Pour une quantité de commande, supposons la règle suivante : seuls les nombres entiers de 1 à 100 inclus sont acceptés. Les chaînes, valeurs absentes et nombres non finis doivent être rejetés. Ce contrat est volontairement simple pour montrer la méthode.

Un test généré qui accepte la chaîne « 2 » parce que le code la convertit implicitement serait ici erroné. Il validerait l'existant au lieu de contrôler la règle convenue.

Construire une matrice de cas avant les assertions

Cette matrice doit être relue avant la génération. Elle peut être plus courte que la suite finale, mais elle donne une référence indépendante. Sur un système réel, ajoutez les cas qui correspondent aux erreurs historiques et aux règles importantes du client.

L'agent peut proposer des scénarios supplémentaires. Chaque proposition doit être évaluée : un cas rare mais critique peut être pertinent, tandis que cent variantes équivalentes peuvent seulement alourdir la maintenance.

Un exemple exécutable avec le test runner de Node.js

Voici une fonction pédagogique en JavaScript, à placer dans un fichier nommé quantity.mjs :

export function isValidQuantity(value) {
  return Number.isInteger(value) && value >= 1 && value <= 100;
}

Les tests suivants vont dans quantity.test.mjs, dans le même répertoire :

import test from "node:test";
import assert from "node:assert/strict";
import { isValidQuantity } from "./quantity.mjs";

test("accepte les entiers aux limites et dans le domaine", () => {
  for (const value of [1, 2, 100]) {
    assert.equal(isValidQuantity(value), true, String(value));
  }
});

test("rejette les valeurs hors contrat", () => {
  for (const value of [
    0, -1, 101, 1.5, "2", true, null, undefined, NaN, Infinity
  ]) {
    assert.equal(isValidQuantity(value), false, String(value));
  }
});

Exécutez node --test quantity.test.mjs avec une version de Node.js prenant en charge ces modules. L'exemple utilise le test runner officiel de Node.js et les assertions strictes ; il n'ajoute aucune dépendance externe.

Ce petit cas ne teste ni interface web, ni base de données, ni autorisation. Son intérêt est de montrer comment une règle et ses frontières deviennent des assertions lisibles.

Demander à Claude Code ou Codex de travailler dans ce cadre

La consigne doit rappeler le contrat et les limites de l'intervention. Elle demande une preuve d'exécution et interdit de modifier arbitrairement le comportement pour rendre la suite verte.

À partir de la règle métier fournie, proposer une matrice de cas.
Attendre sa validation si une règle est ambiguë.
Écrire des tests dans le framework déjà utilisé par le dépôt.
Ne pas modifier l'implémentation pendant cette étape.
Exécuter les tests ciblés et rapporter la commande et son résultat.
Signaler les scénarios non couverts et les vérifications impossibles.

La documentation des bonnes pratiques Claude Code recommande de fournir des critères de vérification. Pour Codex, les instructions AGENTS.md peuvent documenter les commandes et conventions du dépôt. Le contrôle réel reste l'exécution et la revue des tests.

Vérifier que le test échoue quand la règle est cassée

Dans une copie pédagogique, remplacez temporairement la limite supérieure inclusive par une limite exclusive. Le cas 100 doit échouer. Si la suite reste verte, elle ne contrôle pas correctement cette frontière ou n'exécute pas le code attendu.

Rétablissez ensuite la fonction correcte et relancez la suite. Cette mutation volontaire n'est pas un changement à livrer : elle sert à vérifier le pouvoir de détection du test. Elle doit rester limitée à un environnement de test autorisé.

Sur un projet plus complexe, utilisez des mutations ciblées : supprimer un contrôle d'erreur, inverser une comparaison ou remplacer une valeur retournée. N'introduisez pas de modification dangereuse dans un environnement partagé pour démontrer un principe.

Les erreurs fréquentes dans les tests générés

Une assertion trop faible. Vérifier seulement qu'une réponse existe ne contrôle ni son contenu ni la règle métier. Préférez l'observation du comportement utile.

Un mock qui masque tout. Si toutes les dépendances importantes sont remplacées par une réponse prédéfinie, le test peut ne rien dire sur l'intégration réelle. Gardez les doubles de test au niveau nécessaire.

Le même algorithme dans le test et le code. Recalculer le résultat attendu avec la même logique peut reproduire le même bug. Utilisez des exemples validés indépendamment.

Un test non exécuté. Un fichier correct en apparence peut être ignoré par la configuration. Vérifiez le nom, la découverte du test et le nombre de cas réellement lancés.

Un test modifié pour accepter la régression. Une modification de l'attendu doit être justifiée par une décision métier, pas par la volonté d'obtenir une sortie verte.

Intégrer le workflow au processus de livraison

Le développeur prépare les cas, l'agent propose les tests, puis le développeur les exécute et relit leur portée. Le réviseur vérifie le lien avec le ticket et les règles métier. La CI rejoue les commandes dans un environnement propre.

Fixez les versions et les dépendances utiles à la reproductibilité. Réduisez les dépendances à l'heure, au réseau et aux données partagées. Un test intermittent peut rendre le signal de validation inutilisable, même si son intention est correcte.

Les tests unitaires doivent être complétés selon le risque par des tests d'intégration et une validation fonctionnelle. Une suite locale verte n'est ni une preuve de déploiement ni une validation du comportement en production.

Mesurer la valeur des tests, pas leur volume

Suivez les régressions détectées avant fusion, les défauts échappés, le temps de revue et la maintenance des tests. Une augmentation de couverture peut être utile, mais doit être interprétée avec la qualité des assertions.

Le guide de ROI pour les ESN aide à inclure ce travail dans le coût total. Sur une application ancienne, le protocole de maintenance legacy montre comment ajouter d'abord des tests de caractérisation.

Questions fréquentes

Un agent peut-il écrire tous les tests sans intervention humaine ?

Il peut en proposer beaucoup, mais l'équipe doit valider les règles, les assertions et la portée. Une grande suite mal orientée peut coûter cher à maintenir tout en laissant passer les défauts importants.

Une couverture de 100 % garantit-elle la qualité ?

Non. Exécuter toutes les lignes ne démontre pas que les assertions vérifient le bon comportement ni que les scénarios métier sont complets.

Faut-il utiliser le même agent pour coder et tester ?

C'est possible, mais le contrat de test doit rester indépendant de l'implémentation. Une revue humaine et des cas définis à l'avance réduisent le risque de reproduire la même erreur des deux côtés.

Organiser un atelier technique sur un dépôt pilote

Hunter BI propose de cadrer un atelier autour d'une règle métier, d'un module autorisé et du framework déjà utilisé. Le livrable attendu comprend les cas, les tests, les preuves d'exécution et une grille de revue.

Demander un atelier tests unitaires avec Claude Code ou Codex. Pour un parcours plus large, consultez les programmes de formation Claude Code et de formation OpenAI Codex.