TDD avec Claude Code pour dbt

Le développement piloté par les tests fonctionne bien avec les agents IA car le TDD donne à l’agent une cible claire et sans ambiguïté. Au lieu de “écris un bon modèle” (subjectif, difficile à vérifier), la cible devient “fais passer ces tests” (objectif, instantanément vérifiable). Claude Code peut itérer en boucle — lancer les tests, voir les échecs, corriger le code, relancer les tests — jusqu’à ce que tout soit vert.

Ce pattern se déroule en cinq étapes.

Le workflow en cinq étapes

Étape 1 : Écrire les tests avant que le modèle n’existe

Commencez par dire à Claude ce que le modèle doit garantir, sans créer d’implémentation :

Écris des tests dbt pour un nouveau modèle mrt__marketing__customer_lifetime_value. Inclure :
- unique + not_null sur customer_id
- accepted_values pour customer_segment
- test de relationships vers base__stripe__customers
Ne crée pas le modèle encore.

Claude crée une entrée schema.yml avec les définitions de tests. À ce stade, le fichier SQL du modèle n’existe pas. C’est intentionnel — vous définissez le contrat avant l’implémentation.

Les tests que vous spécifiez doivent inclure les types de tests standard : unique et not_null sur les clés primaires, relationships sur les clés étrangères, accepted_values sur les colonnes catégorielles, et toutes les règles métier que vous pouvez exprimer comme tests génériques.

Étape 2 : Confirmer que les tests échouent

Lance dbt test --select mrt__marketing__customer_lifetime_value et confirme que tous les tests échouent.

Cette étape importe pour deux raisons. Premièrement, elle vérifie que les tests sont syntaxiquement valides et correctement liés au modèle (qui n’existe pas encore). Deuxièmement, elle établit le cycle rouge-vert — Claude voit les échecs, qui deviennent sa cible pour l’étape suivante.

Étape 3 : Implémenter pour faire passer

Implémente mrt__marketing__customer_lifetime_value pour faire passer tous les tests.
Ne modifie pas les tests.

L’instruction “ne modifie pas les tests” est critique. Sans elle, Claude peut prendre le chemin de moindre résistance : changer un test pour correspondre à une implémentation plus simple plutôt que d’écrire l’implémentation correcte pour correspondre au test. Les tests sont le contrat. L’implémentation s’adapte au contrat, pas l’inverse.

Claude créera le SQL du modèle, lancera les tests, et itérera si quelque chose échoue. C’est là que le pattern d’agent IA brille — Claude gère l’ensemble de la boucle construction-test-correction au sein d’un seul tour de conversation.

Étape 4 : Itérer sur les échecs

Le test de relationships échoue. Corrige l'implémentation sans changer le test.

Si l’implémentation de Claude ne fait pas passer tous les tests du premier coup, vous n’avez pas besoin de diagnostiquer le problème vous-même. Pointez Claude vers le test en échec et laissez-le investiguer. Il lira le SQL compilé, vérifiera la logique du test, examinera les données en amont, et corrigera l’implémentation.

Étape 5 : Refactoriser avec confiance

Maintenant que les tests passent, refactorise les CTEs pour une meilleure lisibilité tout en maintenant tous les tests verts.

Une fois que tous les tests passent, vous avez un filet de sécurité. La refactorisation devient peu risquée car tout changement qui casse le comportement fera échouer un test. Claude peut restructurer les CTEs, renommer les colonnes intermédiaires, extraire la logique commune, et améliorer la lisibilité — puis vérifier immédiatement que rien n’est cassé.

Pourquoi cela fonctionne avec les agents IA

Le TDD traditionnel a des frictions : écrire les tests en premier semble lent, lancer les tests manuellement entre les itérations est fastidieux, et passer l’étape “rouge” est tentant.

Avec Claude Code, Claude écrit le YAML de test, lance les tests, voit les résultats, et itère sans intervention manuelle. L’ensemble du cycle rouge-vert-refactor peut se passer en un seul tour de conversation. Claude suit également l’instruction “ne modifie pas les tests” à la lettre — les développeurs humains sous pression de temps modifient parfois les tests qui échouent au lieu de corriger les implémentations qui échouent, mais Claude ne le fait pas.

Automatiser la génération de tests

Vous pouvez créer une commande slash qui analyse un modèle et génère les tests appropriés. Sauvegardez ceci comme .claude/commands/generate-tests.md :

---
description: Générer des tests dbt complets pour un modèle
allowed-tools: Read, Write, Bash(dbt:*)
argument-hint: [model_name]
---
Analyser $ARGUMENTS et générer les tests appropriés :

1. Lire le SQL du modèle et le schema.yml existant
2. Identifier les colonnes de clé primaire → ajouter unique + not_null
3. Trouver les relationships de clé étrangère → ajouter les tests relationships
4. Détecter les colonnes de type enum → ajouter accepted_values
5. Trouver les plages numériques → ajouter les tests de plage appropriés

Mettre à jour le schema.yml avec les nouveaux tests.

Tapez /generate-tests mrt__sales__orders et Claude analyse le modèle, identifie ce qui devrait être testé, et met à jour votre schema.yml. Ce n’est pas un substitut à la réflexion sur ce que votre modèle garantit, mais cela attrape les évidences — les tests de clé primaire, les vérifications d’intégrité référentielle, les validations d’enum — et vous donne un point de départ à développer.

Appliquer la discipline

Claude saute parfois les tests ou écrit l’implémentation en premier, en particulier dans les conversations plus longues où les instructions antérieures se désactivent. Vous pouvez utiliser les hooks Claude Code pour appliquer la discipline TDD en interceptant les modifications de fichiers :

Un hook PreToolUse qui bloque la création du SQL du modèle quand il n’existe pas de tests YAML correspondants
Un hook qui valide les changements contre les violations courantes : implémenter des fonctionnalités sans test en échec, modifier les tests pour les faire passer (au lieu de modifier l’implémentation)

Le pattern /test-prompt ajoute une autre couche de sécurité : avant d’utiliser un prompt sur du code de production, lancez-le d’abord sur un modèle sandbox. La commande vérifie la sortie pour la syntaxe BigQuery correcte, l’utilisation appropriée de ref() et source(), et documente les cas limites. Testez sur des modèles non-production avant d’exécuter quelque chose sur l’ensemble de votre projet.

Quand le TDD est pertinent (et quand il ne l’est pas)

Le TDD avec Claude Code a la plus haute valeur pour :

Les nouveaux modèles mart avec une logique métier complexe — les modèles où se tromper a de vraies conséquences
La refactorisation de modèles existants — écrivez d’abord des tests capturant le comportement actuel, puis restructurez
Les modèles avec des cas limites délicats — limites de dates, gestion des nulls, calculs multi-devises

Sa valeur est moindre pour :

Les modèles de base simples qui ne font que renommer et caster des colonnes — des tests génériques sur les clés primaires suffisent
Les requêtes exploratoires ponctuelles qui ne persistent pas
Les modèles où vous êtes encore en train de définir le schéma — écrire des tests pour quelque chose que vous allez redessiner deux fois est un effort gaspillé

Le point idéal est tout modèle pour lequel vous pouvez articuler ce que “correct” signifie avant d’écrire le SQL. Si vous ne pouvez pas décrire le comportement attendu dans des tests, vous ne comprenez probablement pas encore suffisamment bien les exigences — et c’est aussi une information précieuse.