Cadre de décision pour les tests dbt

Un cadre à trois questions pour choisir la bonne approche de test dbt parmi les tests unitaires natifs, les tests génériques, les tests singuliers, dbt-expectations, Elementary et dbt-audit-helper. Répondez aux questions dans l’ordre pour identifier l’outil approprié pour chaque scénario.

Question 1 : Que testez-vous ?

La première question est la plus importante. Différentes catégories de problèmes appellent des outils fondamentalement différents.

Le pattern ici : si vous testez la logique (mon SQL est-il correct ?), vous voulez des tests unitaires avec des données mockées. Si vous testez les données (mes données de production sont-elles saines ?), vous voulez des tests de données contre l’entrepôt. Si vous testez des surprises (se passe-t-il quelque chose d’étrange que je n’avais pas anticipé ?), vous voulez la détection d’anomalies d’Elementary.

Question 2 : Quand voulez-vous détecter les problèmes ?

Le timing est aussi important que le choix d’outil. Différents outils s’exécutent à différents moments du cycle de vie du pipeline, et les placer correctement détermine si vous détectez les problèmes avant ou après que les dommages sont faits.

Les tests unitaires bloquent les déploiements. Ils s’exécutent en CI quand vous poussez des changements de code. Si un test unitaire échoue, le changement de code ne fusionne pas. Ils ne voient jamais les données de production, ce qui signifie qu’ils ne peuvent pas vous protéger des problèmes de qualité des données — mais ils détectent les bugs logiques qu’aucune quantité de tests de données ne trouverait.

Les tests de données bloquent le flux de données en production. Ils s’exécutent à chaque dbt build sur des données d’entrepôt réelles. Un test de données en échec avec la sévérité error empêche les modèles en aval de s’exécuter. Ils détectent les problèmes que le code correct ne peut pas prévenir : les systèmes sources envoyant des NULL là où ils ne l’ont jamais fait, les enregistrements en double depuis des APIs fournisseurs, les décalages soudains de volume de données.

Elementary s’exécute en continu en production, apprenant les patterns depuis les données historiques. Il détecte les « inconnues inconnues » — les anomalies que vous n’auriez pas pensé à écrire des tests explicites pour.

dbt-audit-helper est un outil de développement. Utilisez-le lors du refactoring des modèles ou de la migration depuis des systèmes legacy. Il prouve que vos changements produisent des résultats identiques. Il n’a pas sa place dans les pipelines de production.

Question 3 : Quelle est votre tolérance en termes de coût et de complexité ?

Chaque approche de test a un coût d’installation, un coût d’exécution et un coût de maintenance en cours. La bonne réponse pour un consultant indépendant gérant 30 modèles est différente d’une équipe data gérant 500.

La recommandation honnête : commencez avec les tests génériques (faible effort, large couverture) et ajoutez de la complexité uniquement quand vous avez des preuves que c’est nécessaire. Une suite de tests unique + not_null sur chaque clé primaire détecte plus d’incidents en production qu’un déploiement Elementary sophistiqué que personne ne maintient.

L’arbre de décision

Quand vous regardez un modèle dans une revue de code et vous demandez « quel type de test cela nécessite-t-il ? », parcourez cet arbre :

Le problème porte sur la LOGIQUE ou les DONNÉES ?
|
+-- LOGIQUE (calcul, transformation, cas limite)
|   +-- La logique est-elle suffisamment complexe pour avoir plausiblement des bugs ?
|       +-- Oui --> Test unitaire
|       +-- Non (passthrough simple, agrégation basique) --> Ignorer
|
+-- DONNÉES (intégrité, qualité, fraîcheur)
    |
    +-- Connaissez-vous le seuil ou la règle exacte ?
    |   +-- Oui, règle simple (unique, not null, accepted values)
    |   |   +-- Test générique
    |   +-- Oui, règle complexe (regex, cross-colonnes, SQL personnalisé)
    |   |   +-- Test singulier ou dbt-expectations
    |   +-- Non, vous voulez une détection adaptative
    |       +-- Elementary
    |
    +-- Validez-vous une migration ?
        +-- dbt-audit-helper

L’arbre commence par le découpage fondamental : logique vs données. Cette seule distinction élimine immédiatement la moitié des options. Si vous testez la logique, les tests unitaires sont le seul outil qui ait du sens — les tests de données ne peuvent pas vérifier la logique parce qu’ils ne contrôlent pas leurs entrées. Si vous testez les données, les tests unitaires sont hors de propos parce qu’ils ne voient jamais les données réelles.

Dans la branche données, le découpage est entre les règles explicites (vous savez ce à quoi ressemble « correct ») et la détection adaptative (vous voulez que le système apprenne ce à quoi ressemble « normal »). Les règles explicites appartiennent aux tests génériques, aux tests singuliers ou à dbt-expectations. La détection adaptative appartient à Elementary.

Référence rapide : aide-mémoire de sélection des tests

Pour le reviewer qui a juste besoin d’une réponse rapide :

Cet aide-mémoire est une version condensée du cadre ci-dessus. Pour les cas incertains, les trois questions — ce que vous testez, quand vous souhaitez le détecter, et quelle est la tolérance en termes de coût et de complexité — fournissent l’analyse plus complète.