Concevoir les tests - 6.2

Talend Software Development Life Cycle Guide de bonnes pratiques

EnrichVersion
6.2
EnrichProdName
Talend Big Data
Talend Big Data Platform
Talend Data Fabric
Talend Data Integration
Talend Data Management Platform
Talend Data Services Platform
Talend ESB
Talend MDM Platform
Talend Real-Time Big Data Platform
task
Administration et monitoring
Création et développement
Déploiement
EnrichPlatform
Studio Talend
Talend Administration Center
Talend Artifact Repository
Talend CommandLine
Talend Repository Manager

Tout en concevant les processus (Jobs et Routes), les développeurs doivent réfléchir aux tests qui les accompagnent : Talend vous recommande d'utiliser la fonctionnalité des Test Cases : elle permet de créer automatiquement des tests types avec son "squelette" dans une instance de test.

Un Test Case est un test exécutable constitué d'une partie immuable extraite du Job ou de la Route d'origine, ainsi que d'autres composants modifiables qui forment le squelette de ce Test Case.

Une instance de test est un ensemble de données vous permettant d'exécuter le Test Case avec les différents paramètres que vous définissez (fichiers d'entrée, de référence, etc.).

Pour plus d'informations, consultez le Guide utilisateur du Studio Talend.

Bonnes pratiques :

  • Il est recommandé de créer et d'utiliser un contexte adapté à son environnement (un contexte Test pour exécuter les Jobs de test avec les métadonnées de cet environnement et un contexte Production pour exécuter les Jobs dans l'environnement de Production).

  • Lorsque la fonctionnalité est conçue et testée, il est recommandé d'utiliser Talend Repository Manager pour passer les éléments vers l'environnement d'Assurance qualité et de Production. Pour plus d'informations, consultez Intégration continue : Déploiement vers les environnements de QA et de Production.

Exemple 1. Créer un Test Case basé sur un Job

Un Job nommé job_load_California_clients est créé dans un projet nommé ci_project. Ce Job a pour but de lire un fichier .csv contenant une liste de clients qui vivent en California, faire correspondre ces clients avec ceux qui viennent du comté d'Orange (Los Angeles) en utilisant un composant tMap, avant de charger le résultat dans une base de données MySQL.

La partie traitement de données (tMap) est utilisée pour créer un Test Case appelé test_process_client_file et permettra aux développeurs de tester, filtrer et faire correspondre les fichiers d'entrée et de sortie.

Notez que le squelette généré dépend du/des composant(s) sélectionnés dans le Job pour créer le test. Ici, le Test Case a pour but de:

  • lire des fichiers de données d'entrée (composants tFileInputDelimited),

  • transformer des données avec un ensemble immuable (éléments INPUT et OUTPUT) basé sur le Job d'origine,

  • écrire les données de sortie (dans un composant tFileOutputDelimited),

  • comparer le fichier tempoaire de sortie (composant tCreateTemporaryFile) à un fichier de référence que vous devez définir, en utilisant un composant tFileCompare,

  • générer le statut d'exécution du Test (OK si exécuté avec succès, Fail si échec) en utilisant un composant tAssert.

Notez que vous pouvez ajouter autant d'instances de tests que vous le souhaitez, ce qui signifie que vous pouvez exécuter le même type de test avec différents fichiers d'entrée et de référence.

Le Test Case est prêt à être is exécuté une fois que l'ensemble de données a été défini dans la vue Test Case, et qu'un groupe de contexte spécifique (appelé Test) a été défini dans la vue Context. L'ensemble de données consiste en plusieurs fichiers de données que vous définissez comme fichiers d'entrée et de référence afin de tester vos données.

Le Test Case a été exécuté avec succès dans l'instance de test, et les fichiers d'entrée et de référence sont identiques.


Une fois que les développeurs ont conçu les tests d'intégration en local dans le Studio, ces tests doivent être automatisés avec des outils d'intégration continue tels que des systèmes de build. Pour plus d'informations, consultez Intégration continue : Exécution des tests.

Exemple 2. Créer un Test Case basé sur une Route

Cet exemple s'applique uniquement aux utilisateurs des produits Talend incluant ESB.

Une Route nommée route_file est créée dans un projet nommé ci_project. Cette Route a pour but de lire un fichier, avant de convertir son contenu en chaînes de type String et d'écrire le résultat dans un log.

La partie traitement de données (cConvertBodyTo et cSplit) est utilisée pour créer un Route Test Case appelé test_route_file et des composants cMock sont utilisés pour simuler des échanges de messages et des endpoints, permettant aux développeurs de tester et faire correspondre les messages d'entrée et de sortie.

For more information

Notez que le squelette généré dépend du/des composant(s) sélectionnés dans la Route pour créer le test. Ici, le Test Case a pour but de:

  • générer des échanges de messages et lire des données test d'entrée (composants cTimer et cMock_1),

  • transformer des données avec un ensemble immuable (éléments INPUT et OUTPUT) basé sur la Route d'origine,

  • vérifier que les messages ont été routés comme attendu et valider le résultat en sortie du Test (nombre de messages, contenu, en-tête, etc.) en utilisant le composant cMock_2.

Notez que vous pouvez ajouter autant d'instances de tests que vous le souhaitez, ce qui signifie que vous pouvez exécuter le même type de test avec différents fichiers d'entrée et de référence.

Le Route Test Case est prêt à être exécuté une fois que l'ensemble de données a été défini dans la vue Test Cases, et qu'un groupe de contexte spécifique (appelé Test) a été défini dans la vue Context. L'ensemble de données consiste en plusieurs fichiers de données que vous définissez comme fichiers d'entrée et de référence afin de tester vos données.

Le Route Test Case a été exécuté avec succès dans l'instance de test, et les fichiers d'entrée et de référence sont identiques.