Organiser les tests unitaires dbt à grande échelle

Au fur et à mesure que votre projet dbt grandit, votre suite de tests unitaires aussi. Un projet mature peut avoir des centaines de tests unitaires sur des dizaines de modèles. Sans organisation, lancer les tests devient lent et sélectionner les tests pertinents devient fastidieux. La solution est une stratégie de tags combinée à un pipeline CI à plusieurs niveaux.

Stratégie de tags

Les tags vous permettent de catégoriser les tests et d’exécuter des sous-ensembles sélectivement. Une stratégie de tags utile a trois dimensions :

Criticité : À quel point ce test est-il important pour bloquer les déploiements ?

critical — Tests qui doivent réussir avant tout déploiement
edge-case — Importants mais non bloquants pour le déploiement

Domaine : Quelle partie du business le modèle sert-il ?

finance, marketing, product, operations

Type de test : Quelle catégorie de bug le test détecte-t-il ?

regression — Prévient la récurrence de bugs connus
smoke-test — Vérifications rapides de la logique principale

unit_tests:
  - name: test_mrt_finance_orders_revenue_calculation
    model: mrt__finance__orders
    config:
      tags: ["critical", "finance", "regression"]
    # ...

  - name: test_mrt_finance_orders_empty_cart
    model: mrt__finance__orders
    config:
      tags: ["edge-case"]
    # ...

Gardez les tags plats et en minuscules. Évitez les hiérarchies profondément imbriquées ou la prolifération de tags. Trois à quatre tags par test est l’équilibre optimal — suffisamment pour permettre une sélection utile, pas au point que les tags eux-mêmes deviennent une surcharge de maintenance.

Niveaux du pipeline CI

Le vrai bénéfice du tagging est l’exécution sélective à différentes étapes de votre pipeline de déploiement :

Niveau 1 : Vérifications de PR (chaque pull request)

dbt test --select tag:critical,test_type:unit

Lancez seulement les tests unitaires critiques. Cela devrait se terminer en 1 à 2 minutes pour donner aux développeurs un retour rapide. Si un test critique échoue, la PR ne peut pas fusionner.

Niveau 2 : Merge sur main (post-merge)

dbt test --select test_type:unit

Lancez tous les tests unitaires — critiques, cas limites, régressions, tout. C’est une validation complète qui prend 5 à 10 minutes. Les échecs ici indiquent que deux PRs qui passaient individuellement interagissent mal, ou qu’un cas limite non critique a été cassé.

Niveau 3 : Déploiement en production

dbt build --exclude-resource-type unit_test

Ne lancez pas de tests unitaires en production. Ils utilisent des données simulées et n’apportent aucune valeur face à des données réelles. Les tests de données sont ce qui appartient aux exécutions de production. C’est la règle la plus importante et celle que les équipes violent le plus souvent.

Sélectionner les tests par domaine

Quand vous travaillez sur des modèles finance, vous n’avez pas besoin de lancer les tests marketing. Les tags permettent un développement ciblé par domaine :

# Tous les tests unitaires finance
dbt test --select tag:finance,test_type:unit

# Tous les tests unitaires marketing pour un modèle spécifique
dbt test --select mrt__marketing__customer_attribution,test_type:unit

C’est particulièrement utile pendant le développement. Au lieu de lancer la suite complète de tests après chaque changement, lancez seulement les tests pertinents aux modèles que vous modifiez. Réservez la suite complète pour la validation pré-merge.

Organisation des fichiers

Pour les projets avec beaucoup de tests unitaires, envisagez de co-localiser les fichiers de test avec les modèles qu’ils testent :

models/
├── intermediate/
│   ├── int__events_processed.sql
│   └── _int__unit_tests.yml        # Tests unitaires pour les modèles intermédiaires
├── marts/
│   ├── finance/
│   │   ├── mrt__finance__orders.sql
│   │   └── _mrt_finance__unit_tests.yml
│   └── marketing/
│       ├── mrt__marketing__attribution.sql
│       └── _mrt_marketing__unit_tests.yml

Le préfixe underscore garde les fichiers de test triés avant les fichiers de modèle. La co-localisation signifie que les développeurs trouvent les tests aux côtés des modèles qu’ils modifient. L’alternative — un répertoire séparé tests/unit/ — fonctionne aussi, mais crée une distance entre les modèles et leurs tests qui ralentit le développement.

La référence à la bibliothèque de patterns

Au fur et à mesure que votre suite de tests grandit, un tableau de référence rapide aide les développeurs à trouver le bon pattern pour leur scénario :

Pattern	Technique clé	Quand l’utiliser
Mode dual incrémental	`is_incremental: false/true` + `this`	Tout modèle incrémental
Plages de dates SCD2	Tester les modèles dérivés consommant des snapshots	Consommateurs de snapshots
Fonctions de fenêtrage	Lignes d’entrée hors ordre + partitions multiples	ROW_NUMBER, LEAD/LAG, totaux cumulés
Limites CASE WHEN	Valeurs limites à chaque seuil	Segments client, niveaux, statuts
Gestion des tables vides	`format: sql` avec `WHERE false`	Modèles qui joignent des tables optionnelles
Gestion des nulls	Lignes null explicites dans les fixtures	Tout modèle d’agrégation

Gardez cette référence dans la documentation contributeur de votre projet ou comme commentaire dans vos fichiers YAML de tests. Quand un développeur doit écrire son premier test unitaire, le bon pattern est à une recherche de distance.