Tests

nhic_dbt utilise le framework de tests intégré de dbt pour valider la qualité des données à chaque couche. Les tests s’exécutent en CI sur chaque PR et bloquent la fusion en cas d’échec.

Tests de schéma

Les tests de schéma sont déclarés dans des fichiers YAML (généralement schema.yml) aux côtés des modèles qu’ils testent. dbt fournit quatre tests génériques intégrés :

Test	Ce qu’il vérifie
`not_null`	La colonne ne contient aucune valeur nulle
`unique`	Toutes les valeurs de la colonne sont distinctes
`accepted_values`	La colonne ne contient que des valeurs issues d’une liste définie
`relationships`	Intégrité des clés étrangères — chaque valeur d’une colonne existe dans la colonne référencée

Exemple de déclaration :


# models/staging/cemr/schema.yml
models:
  - name: stg_cemr__patients
    columns:
      - name: patient_id
        tests:
          - not_null
          - unique
      - name: national_id
        tests:
          - not_null
      - name: gender
        tests:
          - accepted_values:
              values: ['M', 'F', 'U']

Tests génériques personnalisés

Les tests propres au projet et réutilisés sur plusieurs modèles se trouvent dans le répertoire tests/ sous forme de tests génériques. Ils suivent le même schéma de déclaration YAML et sont référencés par leur nom dans les fichiers schema.yml.

Utilisez des tests personnalisés pour les assertions propres au domaine — par exemple, valider qu’une date se situe dans une plage attendue, ou qu’un code d’établissement existe dans la table de référence des seeds.

Exécuter les tests


# Run all tests
dbt test
 
# Test a specific layer
dbt test --select staging
dbt test --select intermediate
 
# Test models with a specific tag
dbt test --select tag:dwh
 
# Test a single model
dbt test --select stg_cemr__patients

Barrière de tests en CI

Les tests s’exécutent automatiquement dans .github/workflows/dbt.yaml sur chaque PR ciblant main. Le workflow lance dbt build (qui exécute les seeds, les modèles et les tests dans l’ordre des dépendances) sur l’environnement de CI.

Un test en échec bloque la fusion de la PR. Corrigez les données ou la logique du modèle en cause — ne désactivez pas les tests pour débloquer une fusion.

dbt build est la commande recommandée en CI car elle respecte le DAG et exécute les seeds avant les modèles, et les modèles avant les tests. Lancer dbt test seul sur un environnement vierge peut échouer si les modèles n’ont pas d’abord été matérialisés.