Accueil›Blog›Test dbt prêt à l'emploi

Tests prêts à l'emploi

Test dbt prêt à l'emploi : refactorer un modèle et écrire les tests

Ce test sépare le vrai analytics engineer de celui qui « a écrit des modèles ». On donne un modèle dbt bancal (table en dur, aucun test) et on demande de le refactorer et de le tester. Ce que le candidat ajoute révèle son réflexe fiabilité. Corrigé inclus.

Data Builder·Juillet 2025·10 min de lecture·Test dbt · analytics engineering · clé en main

Sommaire

Le modèle de départ (à refactorer)
Le corrigé
Ce qu'on évalue
Grille par niveau

Le cœur du test : remplacer les tables en dur par des ref()/source() (pour le lineage) et ajouter des tests (unicité, non-nul). Un candidat qui ne teste pas fait du SQL, pas de l'analytics engineering.

1Le modèle de départ (à refactorer)

La consigne

« Ce modèle marche mais est fragile. Refactore-le et ajoute des tests. »

Un modèle typique de débutant : un nom de table écrit en dur (qui casse le lineage) et aucun test. Le candidat doit repérer les deux problèmes.

-- models/clients_actifs.sql (version fragile)
SELECT id, nom, pays
FROM analytics.clients        -- table en dur : casse le lineage
WHERE statut = 'actif'

2Le corrigé

La consigne

ref/sources + tests, la vraie valeur de dbt.

Un bon candidat remplace la table en dur par une source, puis ajoute des tests dans le fichier YAML. C'est ce qui garantit que le modèle ne casse pas ce qui est en aval.

-- models/clients_actifs.sql
SELECT id, nom, pays
FROM {{ source('crm', 'clients') }}   -- source declaree, lineage OK
WHERE statut = 'actif'

-- models/schema.yml
models:
  - name: clients_actifs
    columns:
      - name: id
        tests: [unique, not_null]     -- garantit l'integrite
      - name: pays
        tests: [not_null]

Utilise source()/ref() : le lineage est reconstruit.
Ajoute des tests (unique, not_null) sur les colonnes clés.
Le modèle devient fiable et intégrable en CI.

Signal d'alerte : le red flag : un candidat qui refactore le SQL mais n'ajoute aucun test. Sans tests, rien ne garantit qu'un changement ne cassera pas les rapports en aval — c'est exactement ce que dbt est censé apporter.

3Ce qu'on évalue

La consigne

Le réflexe fiabilité, pas la syntaxe.

On note surtout la présence des tests et l'usage de ref/sources. Un candidat qui y pense spontanément a la bonne culture d'analytics engineering.

Remplace les tables en dur par source()/ref().
Ajoute des tests pertinents (pas juste pour la forme).
Explique comment ça protège l'aval.
Pense documentation et intégration continue (CI).

4Grille par niveau

Niveau	Maîtrise attendue	Signal GO	NO-GO
Junior	Refactore le SQL	Nettoie et clarifie le modèle	Garde un nom de table en dur
Confirmé	Utilise ref/sources	Reconstruit le lineage	N'ajoute aucun test
Senior	Ajoute des tests pertinents	Garantit la non-régression aval	Teste pour la forme, sans logique
Lead	Pense CI, doc, conventions	Intègre le modèle dans un pipeline fiable	Confond dbt et écrire du SQL

Home›Blog›Ready-to-use dbt test

Ready-to-use tests

Ready-to-use dbt test: refactor a model and write the tests

This test separates the real analytics engineer from one who ‘wrote models’. You give a shaky dbt model (hard-coded table, no tests) and ask to refactor and test it. What the candidate adds reveals their reliability reflex. Answer included.

Data Builder·July 2025·10 min read·dbt test · analytics engineering · turnkey

Contents

The starting model (to refactor)
The answer
What we assess
Level grid

The core of the test: replace hard-coded tables with ref()/source() (for lineage) and add tests (uniqueness, not-null). A candidate who doesn't test does SQL, not analytics engineering.

1The starting model (to refactor)

The task

‘This model works but is fragile. Refactor it and add tests.’

A typical beginner model: a hard-coded table name (breaking lineage) and no tests. The candidate must spot both problems.

-- models/clients_actifs.sql (version fragile)
SELECT id, nom, pays
FROM analytics.clients        -- table en dur : casse le lineage
WHERE statut = 'actif'

2The answer

The task

ref/sources + tests, the real value of dbt.

A good candidate replaces the hard-coded table with a source, then adds tests in the YAML file. That's what guarantees the model doesn't break what's downstream.

-- models/clients_actifs.sql
SELECT id, nom, pays
FROM {{ source('crm', 'clients') }}   -- source declaree, lineage OK
WHERE statut = 'actif'

-- models/schema.yml
models:
  - name: clients_actifs
    columns:
      - name: id
        tests: [unique, not_null]     -- garantit l'integrite
      - name: pays
        tests: [not_null]

Uses source()/ref(): lineage is rebuilt.
Adds tests (unique, not_null) on key columns.
The model becomes reliable and CI-ready.

Warning signal : the red flag: a candidate who refactors the SQL but adds no tests. Without tests, nothing guarantees a change won't break downstream reports — which is exactly what dbt is meant to provide.

3What we assess

The task

The reliability reflex, not syntax.

We mainly score the presence of tests and the use of ref/sources. A candidate who thinks of it spontaneously has the right analytics-engineering culture.

Replaces hard-coded tables with source()/ref().
Adds relevant tests (not just for show).
Explains how it protects downstream.
Thinks documentation and continuous integration (CI).

4Level grid

Level	Expected proficiency	Signal GO	NO-GO
Junior	Refactors the SQL	Cleans and clarifies the model	Keeps a hard-coded table name
Mid-level	Uses ref/sources	Rebuilds the lineage	Adds no tests
Senior	Adds relevant tests	Guarantees downstream non-regression	Tests for show, no logic
Lead	Thinks CI, docs, conventions	Integrates the model into a reliable pipeline	Confuses dbt with writing SQL

Test dbt prêt à l'emploi : refactorer un modèle et écrire les tests

1Le modèle de départ (à refactorer)

2Le corrigé

3Ce qu'on évalue

4Grille par niveau

Ready-to-use dbt test: refactor a model and write the tests

1The starting model (to refactor)

2The answer

3What we assess

4Level grid

Vous recrutez un profil data ?