Test de Contrat pour le Développement Piloté par l'IA avec OpenClaw

Les tests de contrat offrent une alternative aux tests d'intégration et de bout en bout lors de l'utilisation d'agents de codage IA comme OpenClaw. Au lieu de tester l'ensemble du système, vous testez les interfaces et les invariants entre les composants, puis demandez à l'agent de générer du code qui satisfait ces contrats.

L'idée centrale

Lorsque vous utilisez un agent pour écrire du code, le flux de travail passe des tests traditionnels au développement piloté par les contrats :

• Écrivez d'abord le contrat/spécification au lieu de l'implémentation
• Les contrats valident l'interface + les invariants au lieu que les tests d'intégration vérifient le comportement
• Tests de fumée E2E minimaux au lieu de tests E2E complets
• L'agent écrit les implémentations au lieu que les humains écrivent la plupart du code

La tâche de l'IA devient : "Faites en sorte que le code satisfasse le contrat."

À quoi ressemble un contrat

Un contrat définit le schéma d'entrée, le schéma de sortie, les invariants et les conditions d'erreur. Exemple en TypeScript avec Zod :

export const CreateUserRequest = z.object({
  email: z.string().email(),
  password: z.string().min(8)
})

export const CreateUserResponse = z.object({
  id: z.string().uuid(),
  email: z.string().email(),
  createdAt: z.string()
})

Exemple de test de contrat :

test("createUser contract", async () => {
  const req = CreateUserRequest.parse({
    email: "[email protected]",
    password: "password123"
  })
  
  const res = await createUser(req)
  expect(CreateUserResponse.parse(res)).toBeDefined()
})

L'IA peut régénérer l'ensemble du service tant que ce test passe.

Modèle de test de contrat pour les agents IA

Une structure de projet courante :

contracts/
  user.contract.ts
  order.contract.ts

tests/
  contract/
    user.test.ts
src/
  services/
    userService.ts

Flux de travail : définissez les contrats, l'agent génère l'implémentation, les tests de contrat s'exécutent, l'agent corrige les échecs. Cela crée une boucle de rétroaction serrée sur laquelle les agents IA s'appuient pour s'auto-corriger.

Exemple d'invite pour l'agent

Dans un flux de travail d'agent OpenClaw :

Implémentez le service pour que tous les tests dans tests/contract passent.
Ne modifiez pas les définitions de contrat. Modifiez uniquement les fichiers d'implémentation.

L'agent itère jusqu'à ce que npm test PASS contract tests.

Contrats pilotés par le consommateur

Les contrats pilotés par le consommateur fonctionnent particulièrement bien pour le développement IA. Exemple : le frontend définit POST /users en s'attendant à { id: uuid, email: string }, et l'agent backend doit satisfaire ce contrat. Les outils généralement utilisés incluent Pact, la validation de schéma et les contrats OpenAPI.

Stack de tests minimale pour le codage IA

Pour remplacer la plupart des tests d'intégration :

contracts/
  openapi.yaml

tests/
  contract/
  invariants/
src/
  implementation

Répartition des tests : tests de contrat (80 %), tests d'invariants/propriétés (15 %), tests de fumée E2E minimaux (5 %). Exemples de tests de fumée : l'inscription utilisateur fonctionne, la connexion utilisateur fonctionne.

Astuce supplémentaire : tests de propriétés

Les agents s'améliorent considérablement avec les tests de propriétés. Exemple :

fc.assert(
  fc.property(fc.string(), async (email) => {
    const user = await createUser({email})
    expect(user.email).toEqual(email)
  })
)

Cela donne à l'agent un espace de recherche pour apprendre.

Pourquoi cela fonctionne mieux pour l'IA

Les agents ont du mal avec la coordination multi-services, les tests E2E instables et la configuration complexe de l'environnement. Ils excellent lorsqu'on leur donne une rétroaction déterministe, des tâches isolées et petites, ainsi que des schémas + contraintes. Les tests de contrat deviennent la "vérité terrain" dans une architecture adaptée à l'IA : contrats (vérité) → tests (vérification) → agent génère → implémentation.