Artefacts de validation du comportement

Les tests sont le mécanisme de vérification principal du comportement attendu du système. Potentiellement généré par l’agent lui-même.

Tests example-based d’acceptance et unitaires

Ancrer sur les critères d’acceptance et exigences EARS. Nous recommandons d’adopter une approche “Outside-In Diamond” car ils documentent le comportement attendu sur des cas nominaux et limites choisis :

• Gros grain (Acceptation) : Documente l’usage et la valeur métier.
• Fin grain (Unité) : Documente la logique interne et les composants.

Pourquoi commencer par les critères d’acceptation ?

Les agents IA produisent de meilleurs résultats lorsque l’objectif est explicite, testable et en démarrant par l’usage externe (approche Outside-In). Le modèle raisonne mieux s’il connaît :

• le comportement attendu dans le cas nominal
• les conditions de succès, sous forme d’assertion sur un retour ou un état après exécution de l’action
• les cas aux limites où l’on vérifie les cas d’erreur.

C’est l’approche à base de scénarios dénommée ATDD (Acceptance Test Driven Development) ou BDD (Behavior Driven Development), ce comportement attendu sous forme de scénarios peut être écrit par l’agent lui-même (en faisant varier les valeurs pour tester les limites, etc.). C’est d’ailleurs une recommandation d’Anthropic : https://www.anthropic.com/engineering/claude-code-best-practices. L’approche de test “Outside-In Diamond” décrite dans cette présentation est un très bon compromis bénéfices / coût lorsque l’on décrit et explore un comportement attendu du système.

Format recommandé : Given / When / Then

**Étant** donné un état
**Quand** je fais cette action
**Alors** je constate que…

L’ATTD peut utiliser d’autres formats comme des tables (table de décisions, de scripts, etc.), voir l’ouvrage ATDD by Example de Markus Gartner.

La valeur d’un scénario tient à son utilisation de vraies valeurs concrétes et réelles, de vrais exemples. C’est l’apport historique du TDD que l’on cherche à préserver, à la fois pour l’humain comme boucle de feedback sur le problème à traiter, et à la fois pour l’agent en tant qu’approche interne (cf. Au-delà du TDD), pour constituer in-fine un oracle supplémentaire.

Les tests sont d’abord un outil de design, puis un outil de vérification dans un second temps. Concevoir, c’est décider du comportement attendu pour répondre aux besoins, d’où l’intérêt de le décrire sous forme de scénarios où la structure Given / When / Then fonctionne bien.

Pour aller plus loin :

• ATDD by example
• Agile Testing
• Specification by Example
• Test Driven Development by Example

Tests Property-based

Les tests property-based sont plus robustes que les tests example-based, car ils ne dépendent pas d’exemples sélectionnés par l’agent ou l’humain. Ils permettent de vérifier des propriétés générales : invariant, idempotence, commutativité, round-trip, métamorphique, potentiellement modélisées par des machines à états. Couplés au fuzzing, ils font émerger les états illégaux que l’example-based ignore. C’est l’oracle qui résiste le mieux aux biais de l’agent.

Tests d’intégration

Le but étant de valider l’adéquation technique entre le code et ses dépendances (contrats d’API, schémas, sérialisation, transactions) soit précisément ce que les mocks masquent. À réserver aux vrais points de contact : plus lents et plus coûteux à maintenir que les tests unitaires, ils n’ont d’intérêt que là où l’intégration peut réellement casser.

Tests de performance

Exprimer des budgets explicites (latence, durée d’exécution avec plusieurs échantillonnages, mémoire, allocations) comme fitness functions. L’objectif étant que « ça reste dans l’enveloppe » avec une détection chiffrée des régressions.