Back to Blog

Pourquoi je ne code plus mes propres tests unitaires (et comment mes agents s'en occupent)

March 18, 2026

Si tu es développeur, tu connais la sensation : tu as une feature géniale en tête, tu veux foncer sur l'implémentation, mais la petite voix du "bon élève" te rappelle que tu devrais d'abord écrire tes tests unitaires.

C'est ce qu'on fait chez Sinaps Conseils sur Actiduo. Le TDD (Test Driven Development) est la règle d'or. Et c'est une excellente règle : elle nous évite de casser la production toutes les deux semaines.

Mais soyons honnêtes : écrire des tests, c'est long. C'est souvent 50% du temps de dev, parfois plus.

Depuis que j'ai mis en place mon équipe d'agents OpenClaw sur mes projets perso comme AutoPrestige, j'ai pris une décision radicale : je ne touche plus à un fichier de test.

Le workflow "Agent-First Testing"

Aujourd'hui, quand je veux ajouter une nouvelle feature, mon workflow ressemble à ça :

  1. Le Brief : Je décris la feature et les "business rules" (ce que ça doit faire, les cas limites).
  2. Le CODER : Mon agent CODER (souvent Claude Code via OpenClaw) crée le squelette de la feature.
  3. Le TESTER : C'est là que la magie opère. Je délègue à un agent spécialisé (le TESTER) la tâche de "casser le code".

L'avantage d'un agent pour les tests ? Il n'a pas la flemme.

Là où un humain va tester le "happy path" (le cas idéal) et peut-être un ou deux cas d'erreurs s'il est motivé, l'agent va en générer 50. Il va tester les null, les undefined, les types improbables, les erreurs de réseau... tout ce qu'on oublie systématiquement à 17h un vendredi.

Un exemple concret : La validation des prix sur AutoPrestige

Pour ma marketplace de voitures de luxe, j'avais besoin d'une fonction qui calcule les frais de service dynamiquement.

Au lieu de coder les tests, j'ai simplement dit à mon agent :

"Lis calculateServiceFee.ts. Écris une suite de tests Vitest complète. Je veux 100% de coverage. Teste les montants négatifs, les devises exotiques, et les limites de précision (flottants)."

Ce que l'agent a généré (en 12 secondes) :

import { describe, it, expect } from 'vitest';
import { calculateServiceFee } from './calculateServiceFee';

describe('calculateServiceFee', () => {
  it('should calculate 5% fee for standard luxury cars', () => {
    expect(calculateServiceFee(100000)).toBe(5000);
  });

  it('should throw error if price is negative', () => {
    expect(() => calculateServiceFee(-100)).toThrow('Price cannot be negative');
  });

  it('should handle zero price (for free listings)', () => {
    expect(calculateServiceFee(0)).toBe(0);
  });

  it('should handle very high amounts without precision loss', () => {
    const hugePrice = 10_000_000;
    expect(calculateServiceFee(hugePrice)).toBe(500_000);
  });
  
  // + 12 autres tests sur les cas limites...
});

L'agent a même trouvé un bug dans mon implémentation initiale sur la gestion des arrondis que je n'aurais probablement vu qu'en production.

Pourquoi c'est mieux que d'écrire soi-même ?

  1. Objectivité totale : En tant que créateur du code, tu as un biais. Tu testes ce que tu as codé. L'agent, lui, teste la spécification.
  2. Vitesse : Générer 20 tests prend 15 secondes. Écrire les mêmes tests à la main prend 30 minutes.
  3. Moral : On garde notre énergie créative pour la logique complexe et l'UX, pas pour la syntaxe répétitive de expect().toBe().

Est-ce que c'est sans risque ?

Non. Le danger, c'est de faire confiance aveuglément à l'agent. Si le prompt est flou, les tests seront flous.

C'est pour ça que dans mon "Swarm" (mon équipe d'agents), j'ai un REVIEWER. Son rôle est de lire les tests générés par le TESTER pour s'assurer qu'ils sont logiques et qu'ils couvrent bien les besoins métier que j'ai définis au départ.

Conclusion

Le métier de développeur en 2026 ne consiste plus à taper des lignes de code répétitives. Il consiste à orchestrer de l'intelligence.

Déléguer ses tests, c'est le premier pas pour passer de "pisseur de code" à "architecte de solutions". Sur valentin.business, je continue d'expérimenter cette approche. Chaque article que vous lisez ici a été validé par un pipeline d'agents avant d'arriver sur votre écran.

Et toi, tu passes encore tes après-midis sur tes mocks ? 😉

PS: Tu veux voir comment j'ai configuré mes agents TESTER ? Abonne-toi à mon flux RSS ou suis-moi sur X/Twitter.

GitHub
LinkedIn
X