Référence des tests dbt-expectations

Référence des tests dbt-expectations les plus utiles par catégorie — des tests qui comblent les lacunes que les tests dbt natifs ne peuvent pas couvrir. Tous les exemples utilisent du SQL compatible BigQuery. dbt-expectations propose plus de 50 tests au total ; cette note couvre les plus largement applicables.

Tests au niveau de la table

expect_row_values_to_have_recent_data

Le dbt natif n’offre des vérifications de fraîcheur que sur les sources. Ce test fonctionne sur n’importe quel modèle, détectant les données obsolètes avant que les tableaux de bord n’affichent des chiffres périmés.

models:
  - name: mrt__sales__orders
    columns:
      - name: order_timestamp
        tests:
          - dbt_expectations.expect_row_values_to_have_recent_data:
              datepart: hour
              interval: 24

Ce test échoue si aucune ligne n’a un order_timestamp dans les dernières 24 heures. Pour les données GA4, qui ont généralement un délai de 24 à 48 heures, définissez interval: 48. Pour les modèles batch quotidiens, utilisez datepart: day avec interval: 2 pour tenir compte des week-ends ou des jours fériés.

expect_table_row_count_to_equal_other_table

Les transformations ne doivent pas supprimer silencieusement des lignes. Ce test le détecte quand elles le font :

models:
  - name: mrt__sales__orders
    tests:
      - dbt_expectations.expect_table_row_count_to_equal_other_table:
          compare_model: ref('base__shopify__orders')

Si votre modèle de base contient 50 000 lignes et que votre mart en a 49 000, quelque chose s’est mal passé entre les deux. C’est particulièrement utile lors des refactorisations — quand vous réécrivez un modèle, le nombre de lignes doit correspondre à l’original sauf si vous avez une raison spécifique pour qu’il diffère.

expect_table_row_count_to_be_between

Détecte les changements de volume inattendus. Si votre batch quotidien contient normalement entre 10 000 et 100 000 lignes et en a soudainement 500, vous souhaitez le savoir avant que quelqu’un n’ouvre un tableau de bord :

models:
  - name: base__ga4__events
    tests:
      - dbt_expectations.expect_table_row_count_to_be_between:
          min_value: 10000
          max_value: 100000

Interrogez les volumes historiques de vos données pour définir des bornes raisonnables. Si vous préférez ne pas maintenir des seuils statiques, le test volume_anomalies d’Elementary apprend le pattern automatiquement. Utilisez expect_table_row_count_to_be_between quand vous connaissez les bornes ; utilisez Elementary quand vous voulez une détection adaptative.

Validation de patterns

expect_column_values_to_match_regex

Le dbt natif n’a pas de tests de validation de format. Ce test couvre cette catégorie :

columns:
  - name: customer_email
    tests:
      - dbt_expectations.expect_column_values_to_match_regex:
          regex: '^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$'

Autres patterns courants :

• user_pseudo_id GA4 : '^[0-9]+\\.[0-9]+$'
• event_name GA4 : '^[a-z_]+$'
• SKU produit comme PRD-1234 : '^PRD-[0-9]{4}$'
• Code pays ISO : '^[A-Z]{2}$'

Combinez toujours les tests regex avec row_condition sur les colonnes nullables. Sans cela, les valeurs NULL échouent à la regex et produisent des faux positifs.

expect_column_values_to_match_like_pattern

Quand les regex sont excessives, utilisez des patterns SQL LIKE à la place. Plus simples à lire, suffisants pour les vérifications de préfixe/suffixe :

columns:
  - name: product_sku
    tests:
      - dbt_expectations.expect_column_values_to_match_like_pattern:
          like_pattern: 'PRD-%'

Validation des plages de valeurs

expect_column_values_to_be_between

Valide que les valeurs sont dans des bornes définies. S’applique aux colonnes numériques et aux dates :

columns:
  - name: order_value
    tests:
      - dbt_expectations.expect_column_values_to_be_between:
          min_value: 0
          max_value: 1000000

  - name: conversion_rate
    tests:
      - dbt_expectations.expect_column_values_to_be_between:
          min_value: 0
          max_value: 1

  - name: event_date
    tests:
      - dbt_expectations.expect_column_values_to_be_between:
          min_value: "'2020-01-01'"
          max_value: "current_date()"

Notez les guillemets pour les valeurs de chaîne et de date : les guillemets extérieurs sont du YAML, les guillemets intérieurs sont du SQL. "'2020-01-01'" devient '2020-01-01' dans la requête compilée.

expect_column_mean_to_be_between

Détecte les décalages de distribution que les vérifications de plage au niveau des lignes manquent. Les valeurs individuelles peuvent toutes être dans les bornes tandis que la distribution globale est anormale :

columns:
  - name: order_value
    tests:
      - dbt_expectations.expect_column_mean_to_be_between:
          min_value: 50
          max_value: 200

Interrogez d’abord les données pour établir des bornes raisonnables (SELECT AVG(order_value) FROM your_model). Les bornes doivent être suffisamment larges pour que les fluctuations normales réussissent, et suffisamment étroites pour que les vraies anomalies échouent.

Pour les colonnes où la moyenne n’a pas de sens (distributions bimodales, valeurs aberrantes importantes), combinez cela avec expect_column_median_to_be_between ou utilisez column_anomalies d’Elementary à la place.

Validation multi-colonnes

expect_compound_columns_to_be_unique

unique natif ne fonctionne que sur une seule colonne. Pour les tables avec une clé primaire composite :

models:
  - name: mrt__sales__order_lines
    tests:
      - dbt_expectations.expect_compound_columns_to_be_unique:
          column_list: ["order_id", "line_item_id"]

Appliquez cela à chaque table avec une clé primaire composite. Les explosions de jointure dues aux doublons de clés composites sont parmi les bugs les plus difficiles à diagnostiquer car ils gonflent silencieusement les métriques plutôt que de produire des erreurs.

expect_column_pair_values_A_to_be_greater_than_B

Valide la logique métier qui s’étend sur deux colonnes :

models:
  - name: mrt__finance__subscriptions
    tests:
      - dbt_expectations.expect_column_pair_values_A_to_be_greater_than_B:
          column_A: end_date
          column_B: start_date
          or_equal: true
          row_condition: "end_date is not null"

Cas d’usage courants :

• shipped_date > order_date
• total_amount >= subtotal
• updated_at >= created_at
• end_date >= start_date

Le paramètre or_equal: true est important — sans lui, les enregistrements où les deux dates sont égales (abonnements le même jour, expéditions instantanées) échoueraient.

Tests d’exhaustivité

expect_row_values_to_have_data_for_every_n_datepart

Détecte les lacunes dans les données de séries temporelles. Si une journée entière d’événements GA4 est manquante, ce test échoue :

columns:
  - name: event_date
    tests:
      - dbt_expectations.expect_row_values_to_have_data_for_every_n_datepart:
          date_col: event_date
          date_part: day
          test_start_date: "'2024-01-01'"
          test_end_date: "current_date() - 1"

Spécifiez toujours les bornes de dates. Sans test_start_date et test_end_date, ce test scanne tout l’historique de votre table. Sur un grand jeu de données GA4, cela signifie scanner des millions de lignes pour rechercher des lacunes depuis le début des temps. Bornez-le à une fenêtre récente (90 jours, un an) pour maintenir les coûts raisonnables.

Pour BigQuery spécifiquement, utilisez des expressions de date sensibles aux partitions :

test_start_date: "date_sub(current_date(), interval 90 day)"
test_end_date: "date_sub(current_date(), interval 2 day)"

La borne de fin à interval 2 day tient compte du délai de traitement typique de GA4 — vous ne voulez pas que le test échoue parce que les données d’aujourd’hui ne sont pas encore arrivées.

Référence rapide

Pour les patterns de configuration des tests (niveaux de sévérité, optimisation des performances, exécution en production uniquement), consultez Sévérité et optimisation des tests dbt. Pour le paramètre row_condition qui fonctionne sur presque tous ces tests, consultez le paramètre row_condition dans dbt-expectations.