Utilisation
test: historic_revenue_is_accurate { explore_source: orders { column: total_revenue { field: orders.total_revenue } filters: [orders.created_date: "2017"] } assert: revenue_is_expected_value { expression: ${orders.total_revenue} = 626000 ;; } }
|
Hiérarchie
test- ou - test- ou - test |
Valeur par défaut
Aucun
Acceptation
Identifiant du test de données, plus sous-paramètres définissant les assertions et la requête du test.
|
Définition
Looker dispose du validateur LookML pour vérifier que votre code LookML est syntaxiquement valide et du validateur de contenu pour vérifier les références d'objet entre votre contenu et votre modèle.
En plus de ces validateurs, le paramètre test vous permet de valider la logique de votre modèle. Pour chaque test de données, vous créez une requête et une instruction d'assertion yesno. Le test de données exécute la requête de test et vérifie que l'assertion est vraie pour chaque ligne de la requête de test. Si l'instruction d'assertion renvoie yes pour chaque ligne de la requête de test, le test de données réussit.
Si les paramètres de votre projet sont configurés pour exiger la réussite des tests de données avant le déploiement en production, et si votre projet comporte un ou plusieurs paramètres test, l'IDE affiche le bouton Exécuter les tests une fois que vous avez validé les modifications apportées au projet. Les développeurs LookML doivent exécuter les tests de données avant de déployer les modifications en production.
Que votre projet nécessite ou non des tests de données avant le déploiement en production, un développeur LookML en mode Développement peut exécuter des tests de données à tout moment pour vérifier la logique du modèle.
Vous pouvez créer des tests de données dans des fichiers de modèle, des fichiers de vue ou dans des fichiers de test de données distincts et dédiés. Lorsque vous utilisez un fichier dédié pour héberger vos tests de données, n'oubliez pas de include le fichier de test de données dans n'importe quel fichier de modèle ou fichier de vue dans lequel vous souhaitez exécuter vos tests de données.
Un test de données ne peut pas avoir le même nom et le même explore_source qu'un autre test de données dans le même projet. Si vous utilisez le même explore_source pour plusieurs tests de données dans votre projet, assurez-vous que les noms des tests de données sont tous uniques.
Le paramètre test comporte les sous-paramètres suivants :
explore_source: définit la requête à utiliser dans le test de données.assert: définit une expression Looker qui est exécutée sur chaque ligne de la requête de test pour vérifier les données.
Une fois que vous avez défini le code LookML pour votre test, vous pouvez exécuter le test de données pour vérifier qu'il fonctionne correctement et voir si la logique de votre modèle réussit le test (vous devez être en mode Développement pour exécuter des tests de données).
Vous pouvez lancer des tests de données pour un projet de plusieurs manières :

- Si les paramètres de votre projet sont configurés pour exiger la réussite des tests de données avant le déploiement de vos fichiers en production, l'IDE affiche le bouton Exécuter les tests une fois que vous avez validé les modifications apportées au projet. Tous les tests de votre projet seront exécutés, quel que soit le fichier qui définit le test. Vous devez réussir les tests de données avant de pouvoir déployer vos modifications en production.
- Dans le panneau État du projet, sélectionnez le bouton Exécuter les tests de données. Tous les tests de données de votre projet seront exécutés, quel que soit le fichier qui définit le test.
- Sélectionnez l'option Exécuter les tests LookML dans le menu du fichier. Seuls les tests définis dans le fichier actuel seront exécutés.
Une fois les tests de données exécutés, le panneau État du projet affiche la progression et les résultats.

Vous pouvez sélectionner le lien Explorer la requête pour chaque résultat de test afin d'ouvrir une exploration avec la requête définie dans le test de données.
explore_source
Le paramètre explore_source d'un test de données utilise la même syntaxe et la même logique que le paramètre explore_source d'une table dérivée. La seule différence est que le explore_source d'un test de données n'est pas compatible avec les sous-paramètres derived_column, bind_filters et bind_all_filters.
Conseil pratique : Pour obtenir facilement le code LookML
explore_source, utilisez une exploration existante pour créer votre requête. Dans l'exploration, sélectionnez Obtenir le code LookML dans le menu en forme d'engrenage de l'exploration, puis sélectionnez l'onglet Table dérivée pour obtenir le code LookML de la requête. Pour en savoir plus, consultez la documentation sur la création de tables dérivées natives.
Notez les points suivants concernant le explore_source d'un test de données :
La requête
explore_sourced'un test de données est une requête Looker standard, ce qui signifie que la requêteexplore_sourcedu test est limitée à 5 000 lignes. Assurez-vous que votre requête ne dépasse pas 5 000 lignes afin d'obtenir un ensemble de résultats complet à tester. Vous pouvez intégrer des filtres ou un tri dans votreexplore_sourcepour réduire le nombre de lignes de votre requête ou pour placer les lignes pertinentes en haut de la requête.Une
exploreavecextension: requiredne peut pas être utilisée commeexplore_sourcepour un test de données. Le validateur LookML génère une erreur indiquant que leexplore_sourceest introuvable.
assert
Le sous-paramètre assert définit les critères selon lesquels le résultat de la requête explore_source est considéré comme valide. Le sous-paramètre expression accepte une expression Looker qui génère un yesno (booléen). Une fois la requête explore_source exécutée, l'expression de l'assertion est évaluée pour chaque ligne de l'ensemble de résultats de la requête. Si une réponse no est renvoyée pour une ligne de la requête, le test de données échoue. Si la requête elle-même comporte des erreurs, le test échoue également.
Un test peut comporter plusieurs déclarations assert. Pour que le test réussisse, chaque assertion doit être vraie pour chaque ligne de la requête explore_source.
Conseil pratique : Vous pouvez utiliser la boîte de dialogue des calculs de table pour tester la syntaxe de l'expression Looker à utiliser dans le paramètre
expressionde votre test.
Pour être utilisés dans les tests de données, les champs de l'expression Looker doivent être entièrement délimités, c'est-à-dire spécifiés au format view_name.field_name. Par exemple, l'expression suivante déclare le champ comme aircraft_engine_types.aircraft_engine_type_id :
assert: engine_type_id_not_null {
expression: NOT is_null(${aircraft_engine_types.aircraft_engine_type_id}) ;;
}
Exemples
S'assurer qu'une clé primaire est unique
Le test de données suivant crée une requête à partir de l'exploration orders et définit une expression pour vérifier que les ID de commande sont uniques dans l'ensemble de résultats. La requête explore_source crée un nombre de lignes associées à chaque ID dans la base de données. Si l'ID est unique, la base de données ne doit comporter qu'une seule ligne pour un ID. De plus, elle trie le nombre et limite l'ensemble de résultats à une seule ligne. La réponse de la requête sera donc l'ID avec le nombre le plus élevé. Si un ID a un nombre supérieur à 1, nous savons qu'il existe plusieurs lignes pour cet ID et que l'ID n'est donc pas unique. Dans ce cas, ce test de données échoue.
test: order_id_is_unique {
explore_source: orders {
column: id {}
column: count {}
sorts: [orders.count: desc]
limit: 1
}
assert: order_id_is_unique {
expression: ${orders.count} = 1 ;;
}
Vérifier une valeur connue
Le test de données suivant vérifie que la valeur des revenus de 2017 est toujours de 626 000 $. Dans cet ensemble de données, il s'agit d'une valeur connue qui ne doit jamais changer.
test: historic_revenue_is_accurate {
explore_source: orders {
column: total_revenue {
field: orders.total_revenue
}
filters: [orders.created_date: "2017"]
}
assert: revenue_is_expected_value {
expression: ${orders.total_revenue} = 626000 ;;
}
}
Confirmer l'absence de valeurs nulles
Le test de données suivant vérifie qu'il n'y a pas de valeurs nulles dans les données. Ce explore_source utilise un sort pour s'assurer que toutes les valeurs nulles sont renvoyées en haut de la requête. Le tri des valeurs nulles peut varier en fonction de votre dialecte. Le test suivant utilise desc: yes comme exemple.
test: status_is_not_null {
explore_source: orders {
column: status {}
sorts: [orders.status: desc]
limit: 1
}
assert: status_is_not_null {
expression: NOT is_null(${orders.status}) ;;
}
}