Accueil›Blog›Test technique dbt testing avancé : singular tests, macros de test, coverage

Guide recrutement data

Test technique dbt testing avancé : singular tests, macros de test, coverage

Les tests dbt vont bien au-delà de not_null et unique. En entretien Senior, on évalue la capacité à écrire des tests sophistiqués qui garantissent réellement la qualité des données.

Data Builder·Juin 2025·6 min de lecture·Analytics Engineer

Sommaire

Tests génériques avancés
Singular tests
Macros de test custom
Stratégie de coverage
Tests en CI
Debugger les tests
Grille

1Tests génériques avancés avec dbt-expectations

Question discriminante

Comment allez-vous au-delà des 4 tests dbt de base ?

# schema.yml - tests avancés avec dbt-expectations
models:
  - name: fct_orders
    columns:
      - name: amount
        tests:
          - not_null
          - dbt_expectations.expect_column_values_to_be_between:
              min_value: 0
              max_value: 1000000
              config:
                severity: error
          - dbt_expectations.expect_column_proportion_of_unique_values_to_be_between:
              min_value: 0.99
      - name: order_date
        tests:
          - dbt_expectations.expect_column_values_to_be_of_type:
              column_type: date
          - dbt_expectations.expect_column_values_to_be_between:
              min_value: '2020-01-01'
              max_value: '{{ modules.datetime.date.today() }}'
    tests:
      - dbt_expectations.expect_table_row_count_to_be_between:
          min_value: 1000
      - dbt_expectations.expect_table_columns_to_match_set:
          column_list: ['order_id', 'customer_id', 'amount', 'status']

2Singular tests : logique SQL custom

Question discriminante

Quand écrivez-vous un singular test plutôt qu un test générique ?

-- tests/fct_orders_no_future_dates.sql
-- Un singular test retourne les LIGNES QUI ÉCHOUENT
-- Si la requête retourne 0 lignes -> test passé
SELECT
    order_id,
    order_date,
    'order_date cannot be in the future' AS test_name
FROM {{ ref('fct_orders') }}
WHERE order_date > CURRENT_DATE

UNION ALL

-- Test de cohérence métier : total ne peut pas être négatif
SELECT
    order_id,
    amount,
    'amount cannot be negative for completed orders' AS test_name
FROM {{ ref('fct_orders') }}
WHERE status = 'completed'
  AND amount < 0

Singular vs générique — singular pour la logique métier complexe qui ne s exprime pas en YAML
Multiple checks — UNION ALL pour regrouper plusieurs vérifications dans un seul test

3Macros de test custom

Question discriminante

Comment créez-vous une macro dbt réutilisable pour tester la fraîcheur d un modèle ?

{# macros/test_freshness_sla.sql #}
{% macro test_freshness_sla(model, column_name, hours=24) %}

SELECT
    MAX({{ column_name }}) AS last_update,
    CURRENT_TIMESTAMP AS checked_at,
    DATEDIFF('hour', MAX({{ column_name }}), CURRENT_TIMESTAMP) AS hours_stale
FROM {{ model }}
HAVING DATEDIFF('hour', MAX({{ column_name }}), CURRENT_TIMESTAMP) > {{ hours }}

{% endmacro %}

{# Utilisation dans schema.yml #}
models:
  - name: fct_orders
    tests:
      - freshness_sla:
          column_name: updated_at
          hours: 6
          config:
            severity: error

4Stratégie de coverage des tests

Question discriminante

Comment évaluez-vous si votre projet dbt est suffisamment testé ?

Coverage minimal — 100% des PKs testés avec unique + not_null. 100% des FKs avec relationships
Colonnes critiques — toutes les colonnes utilisées dans les KPIs métier ont au moins 1 test
Script de coverage — requêter INFORMATION_SCHEMA pour identifier les colonnes sans test
dbt-coverage — package qui génère un rapport de coverage documentation + tests par modèle
Pre-commit hook — bloquer le commit si un nouveau modèle n a pas au moins not_null sur sa PK

5Tests en CI : vitesse et fiabilité

Question discriminante

Comment rendez-vous vos tests dbt rapides en CI sans les désactiver ?

# Ne tester que les modèles modifiés (slim CI)
dbt test \
  --select state:modified+ \
  --defer \
  --state ./prod-artifacts

# Séparer les tests par sévérité
# En CI sur PR : uniquement les tests error
dbt test --select state:modified+ --warn-error

# En CI sur main : tous les tests
dbt test

# Tags pour catégoriser les tests
tests:
  - name: fct_orders
    tests:
      - not_null:
          config:
            tags: ['critical']
            severity: error
      - dbt_expectations.expect_table_row_count_to_be_between:
          config:
            tags: ['non_critical']
            severity: warn

6Debugger les tests qui échouent

Question discriminante

Comment investiguer un test dbt qui échoue en production ?

dbt test --store-failures — stocker les lignes en échec dans une table de debug dans le warehouse
--select model_name — relancer uniquement le test qui pose problème
dbt compile --select test_name — voir le SQL généré par le test sans l exécuter
Requêter la table failures — SELECT * FROM dbt_test__audit.not_null_fct_orders_order_id

7Grille par niveau

Niveau	Maitrise	Signal GO	NO-GO
Confirmé	Tests YAML, dbt-expectations, singular tests	A écrit des singular tests, utilise dbt-expectations	N utilise que not_null et unique
Senior	Macros de test, coverage strategy, CI optimisé	A créé des macros de test réutilisables, stratégie de coverage documentée	Ne sait pas écrire une macro de test

Vous recrutez un Analytics Engineer dbt Senior ?

Premier entretien gratuit. Rapport GO/NO-GO sous 48h.

Tester gratuitement Reserver un appel