Écrire des tests unitaires avec Claude Code : le guide TDD complet (2026)

Écrire des tests unitaires avec Claude Code : pourquoi c'est la compétence clé de 2026

En 2026, un agent comme Claude Code écrit du code à une vitesse déconcertante. Le vrai goulot d'étranglement n'est plus la production de code, mais sa fiabilité. Comment savoir qu'une fonction générée en langage naturel fait bien ce qu'elle doit faire — et qu'elle ne casse rien ailleurs ? La réponse tient en deux mots : tests unitaires. Loin d'être une corvée réservée aux grandes équipes, l'écriture de tests devient, avec l'IA, à la fois plus rapide et plus stratégique.

Ce guide montre, étape par étape, comment écrire des tests unitaires avec Claude Code et adopter le workflow TDD (Test-Driven Development, ou développement piloté par les tests). Vous verrez comment installer un framework de test, faire écrire les tests par l'agent, appliquer le cycle *red-green-refactor*, gérer les mocks et la couverture de code, puis brancher le tout dans une pipeline d'intégration continue. Si vous débutez avec l'agent, gardez à portée notre guide complet de Claude Code, qui pose les bases du travail en mode agentique.

Sommaire

Pourquoi tester quand c'est l'IA qui code<a id="pourquoi-tester"></a>

L'intuition première est trompeuse : « si l'IA écrit du bon code, pourquoi tester ? ». Justement parce que l'agent produit beaucoup de code, très vite, sur une large surface. Sans tests, chaque modification devient un pari : vous ne savez pas si la nouvelle fonctionnalité a introduit une régression trois fichiers plus loin.

Les tests unitaires jouent trois rôles complémentaires dans un workflow assisté par IA. D'abord, ils spécifient le comportement attendu : un test bien écrit est une définition exécutable de ce que le code doit faire. Ensuite, ils détectent les régressions : quand Claude Code refactorise ou ajoute une fonctionnalité, la suite de tests vous alerte immédiatement si quelque chose casse. Enfin, ils guident l'agent : un test qui échoue donne à Claude Code un objectif concret et vérifiable, bien plus efficace qu'une consigne floue.

Cette boucle « je décris, l'agent code, les tests valident, l'agent corrige » est le cœur d'un développement agentique sérieux — l'exact opposé du code généré à l'aveugle. C'est aussi ce qui rend le refactoring de code legacy avec Claude Code réellement sûr : sans filet de tests, refactoriser du vieux code est une roulette russe.

Installer un framework de test avec Claude Code<a id="installation"></a>

Vous n'avez pas besoin de tout configurer à la main. Ouvrez Claude Code dans votre projet et laissez-le mettre en place l'outillage. Pour un projet JavaScript/TypeScript moderne, Vitest est le choix le plus rapide et le plus simple en 2026 :

« Ajoute Vitest à ce projet, configure le fichier de configuration, ajoute un script `npm test` dans package.json et crée un test d'exemple qui passe pour vérifier l'installation. »

L'agent exécute alors les commandes d'installation, écrit la configuration et lance un premier test. En coulisses, cela ressemble à :

npm install -D vitest
npm test

Pour un projet Python, la démarche est identique avec Pytest :

pip install pytest pytest-cov
pytest

Prenez l'habitude de consigner votre choix de framework et vos conventions de test dans le fichier CLAUDE.md à la racine du projet. L'agent le lit à chaque session : « Utilise Vitest pour tous les tests, un fichier *.test.ts par module, pas de test qui dépend du réseau réel ». Ces règles, écrites une fois, garantissent des tests cohérents dans tout le projet — un principe détaillé dans nos meilleures pratiques Claude Code.

Le workflow TDD avec Claude Code : red-green-refactor<a id="tdd"></a>

Le TDD (développement piloté par les tests) inverse l'ordre habituel : on écrit d'abord le test, puis le code qui le fait passer. Avec un agent, cette approche est particulièrement puissante, car le test devient un cahier des charges exécutable que l'IA doit satisfaire.

Le cycle TDD se déroule en trois temps, le fameux red-green-refactor :

Avec Claude Code, un prompt TDD efficace ressemble à ceci :

« Nous allons faire du TDD. Écris d'abord les tests Vitest pour une fonction `calculerTVA(montantHT, taux)` qui retourne le montant TTC arrondi à deux décimales et lève une erreur si le taux est négatif. Ne code pas encore la fonction. Lance les tests et montre-moi qu'ils échouent. »

Une fois les tests validés et rouges, vous enchaînez :

« Maintenant, implémente `calculerTVA` pour faire passer tous les tests. **Ne modifie pas les tests.** Relance la suite jusqu'à ce que tout soit vert. »

Cette consigne « ne modifie pas les tests » est cruciale. Par défaut, un agent cherche le chemin le plus court vers le vert — quitte à affaiblir une assertion. En verrouillant les tests, vous forcez l'implémentation à se conformer à la spécification, et non l'inverse. C'est le même esprit de rigueur que celui du mode plan de Claude Code, où l'on cadre le travail avant d'écrire la moindre ligne.

Écrire ses premiers tests unitaires en JavaScript/TypeScript<a id="premiers-tests"></a>

Prenons un exemple concret. Vous demandez à Claude Code de tester une fonction utilitaire. Voici le genre de test que l'agent produit avec Vitest :

import { describe, it, expect } from "vitest";
import { calculerTVA } from "./tva";

describe("calculerTVA", () => {
  it("calcule le TTC avec un taux de 20 %", () => {
    expect(calculerTVA(100, 0.2)).toBe(120);
  });

  it("arrondit à deux décimales", () => {
    expect(calculerTVA(99.99, 0.2)).toBe(119.99);
  });

  it("lève une erreur si le taux est négatif", () => {
    expect(() => calculerTVA(100, -0.1)).toThrow();
  });
});

Trois cas, trois intentions claires : le cas nominal, un cas d'arrondi, et un cas d'erreur. C'est exactement ce qui manque quand on teste à la va-vite. Demandez systématiquement à l'agent de couvrir les cas limites : « ajoute des tests pour montant nul, montant négatif, et taux à zéro ». Vous obtenez en quelques secondes une couverture que peu de développeurs prennent le temps d'écrire à la main.

Le même principe s'applique au test de composants front (React, Vue, Svelte) avec des outils comme Testing Library : décrivez le comportement attendu à l'écran (« quand je clique sur le bouton, le compteur passe à 1 ») et l'agent génère le test correspondant.

Tester du code Python avec Pytest<a id="pytest"></a>

Côté Python, Pytest reste la référence en 2026 pour sa syntaxe minimaliste. Un test généré par Claude Code ressemble à :

import pytest
from panier import total_panier

def test_total_panier_simple():
    articles = [{"prix": 10, "qte": 2}, {"prix": 5, "qte": 1}]
    assert total_panier(articles) == 25

def test_total_panier_vide():
    assert total_panier([]) == 0

def test_total_panier_quantite_negative():
    with pytest.raises(ValueError):
        total_panier([{"prix": 10, "qte": -1}])

La force de Pytest est la paramétrisation, que l'agent maîtrise très bien. Demandez : « transforme ces tests en un test paramétré avec @pytest.mark.parametrize couvrant cinq combinaisons prix/quantité ». Vous obtenez une batterie de cas compacte et lisible. Pour aller plus loin sur l'écosystème Python et l'IA open-source, le site partenaire formation-openclaw.com explore les agents IA auto-hébergés, un complément utile quand vos tests touchent à des pipelines de données sensibles.

Mocks, stubs et tests d'intégration<a id="mocks"></a>

Un test unitaire doit rester isolé : il ne doit pas dépendre d'un vrai serveur, d'une vraie base de données ou d'un appel réseau réel. C'est le rôle des mocks (simulacres) et des stubs. Claude Code excelle à générer ces doublures.

Imaginons une fonction qui récupère des données via une API externe — par exemple une API immobilière comme immoapi.app pour agréger des annonces. Vous ne voulez surtout pas appeler l'API réelle dans vos tests. Demandez à l'agent :

« Écris un test pour `recupererAnnonces()` en mockant l'appel HTTP avec `vi.mock`. Simule une réponse réussie, puis une réponse en erreur 500, et vérifie que la fonction gère les deux cas. »

L'agent produit alors un test qui simule les réponses réseau, sans jamais sortir de la machine :

import { vi, describe, it, expect } from "vitest";
import { recupererAnnonces } from "./annonces";

vi.mock("./httpClient", () => ({
  get: vi.fn(),
}));

describe("recupererAnnonces", () => {
  it("retourne les annonces en cas de succès", async () => {
    // ... configuration du mock et assertions
  });
});

Cette maîtrise des mocks est décisive : elle rend vos tests rapides, déterministes et exécutables hors ligne. Un test qui dépend du réseau réel est un test qui échouera un jour au mauvais moment.

Couverture de code et cas limites<a id="couverture"></a>

La couverture de code (code coverage) mesure la proportion de votre code réellement exécutée par les tests. Ce n'est pas une fin en soi — 100 % de couverture avec des assertions creuses ne prouve rien — mais c'est un excellent radar pour repérer les zones oubliées.

Demandez à Claude Code de lancer la couverture et d'analyser le rapport :

# JavaScript / TypeScript
npx vitest run --coverage

# Python
pytest --cov=mon_module

Puis : « analyse le rapport de couverture et écris des tests pour les branches non couvertes ». L'agent identifie les if jamais empruntés, les cas d'erreur non testés, les valeurs de bord ignorées, et complète la suite. C'est là que l'IA fait gagner un temps considérable : générer des tests pour les cas limites est fastidieux à la main, mais quasi instantané pour un agent bien piloté.

Voici la vidéo ci-dessous, qui illustre concrètement le cycle TDD avec Claude Code — écrire les tests d'abord, laisser l'agent implémenter, puis vérifier que tout reste honnête. Un bon complément visuel à ce guide pour voir le workflow en action :

Intégrer les tests dans la CI et les hooks<a id="ci"></a>

Une suite de tests ne vaut que si elle tourne automatiquement. Deux niveaux d'automatisation se complètent.

D'abord, les hooks Claude Code : vous pouvez configurer un hook qui relance la suite de tests après chaque modification de fichier par l'agent. Ainsi, si une génération casse un test, vous le savez sur-le-champ, dans la même session. Notre guide sur les hooks Claude Code pour automatiser votre workflow détaille cette mécanique.

Ensuite, l'intégration continue. Demandez à l'agent de créer un workflow GitHub Actions :

« Crée un fichier `.github/workflows/test.yml` qui installe les dépendances, lance la suite de tests sur chaque push et pull request, et fait échouer le build si un test casse. »

name: Tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "22"
      - run: npm ci
      - run: npm test

Vos tests deviennent alors un filet de sécurité continu : aucune fusion ne passe sans que la suite soit verte. Pour aller plus loin sur l'automatisation de bout en bout, consultez notre guide Claude Code et les pipelines CI/CD DevOps.

Bonnes pratiques et pièges à éviter<a id="bonnes-pratiques"></a>

Quelques principes distinguent une suite de tests solide d'un empilement de tests illusoires :

Ces réflexes s'inscrivent dans une pratique plus large du développement assisté par IA, dont nous détaillons la philosophie dans notre article sur le vibe coding avec Claude Code. Écrire des tests n'est pas l'ennemi de la vitesse : bien menés avec un agent, les tests sont ce qui vous permet d'aller vite sans casser.

Passez à la vitesse supérieure

Vous savez désormais écrire des tests unitaires avec Claude Code et appliquer un vrai workflow TDD. La prochaine étape est de faire de cette rigueur un automatisme quotidien — et, plus largement, de laisser l'IA prendre en charge les tâches répétitives de votre métier de développeur.

👉 Découvrez comment déléguer une grande partie de votre travail à l'IA et vous concentrer sur l'essentiel : se faire remplacer par l'IA.

---

*Cet article fait partie de notre série de guides pratiques sur Claude Code. Pour aller plus loin, explorez le guide complet de Claude Code et nos meilleures pratiques.*