Cet article décrit une stratégie de tests avancée dans dbt, particulièrement utile quand tu travailles sur des modèles complexes avec plusieurs étapes de transformation (calculs, agrégats, joins, etc.).
🧠 Idée clé
Au lieu de ne tester que le résultat final,
on teste aussi les résultats intermédiaires dans la chaîne de transformation.
Cela te permet de :
- détecter plus vite où un bug se produit
- isoler une étape fautive
- maintenir plus facilement ton pipeline
🧱 Exemple concret
🧩 Cas d’un modèle complexe (mart final)
Imaginons cette chaîne de transformation :
source('raw', 'commandes') → stg_commandes → fct_commandes → mart_ventes
Tu peux avoir :
- des fenêtres (
ROW_NUMBER,SUM OVER) - des jointures multiples
- des filtres métier
✅ Mauvaise stratégie (test minimal)
Tu ne testes que le résultat final mart_ventes, avec :
tests:
- unique
- not_null
👉 Si un test échoue, tu ne sais pas où le problème est apparu.
✅ Bonne stratégie : tester chaque étape intermédiaire
| Modèle | Exemple de test |
|---|---|
stg_commandes | not_null sur commande_id, valid_date |
fct_commandes | test de somme, test de jointure manquante |
mart_ventes | test métier final (unique, seuil, cohérence…) |
✅ Exemple réel :
Test intermédiaire sur fct_commandes :
models:
- name: fct_commandes
columns:
- name: montant_total
tests:
- expression_is_true:
expression: "montant_total >= 0"
Test final sur mart_ventes :
models:
- name: mart_ventes
columns:
- name: id_vente
tests:
- unique
- not_null
🔍 Avantages
| Avantage | Détail |
|---|---|
| 🎯 Diagnostic précis | Tu sais quelle étape a échoué |
| 🛠 Maintenance facile | Tu évites de tout casser à cause d’un bug en amont |
| 🔁 Revue de code + fiable | Tu vérifies la logique métier à chaque niveau |
| ✅ Bonne pratique data ops | Conforme aux approches CI/CD modernes |
🧠 Résumé
| Principe | Explication |
|---|---|
| Tester intermédiaire + final | Meilleure couverture, meilleure visibilité |
| Isoler les erreurs plus vite | Gain de temps au debug |
| Tests adaptés à chaque étape | not_null, expression_is_true, accepted_values, etc. |
| Plus de confiance dans les refactors | Tu sais si une modif a cassé une logique précise |