Accéder au contenu principal

Exemple de Test case basé sur un Job

Un Job nommé job_feature400 est créé dans un projet nommé CI. Ce Job a pour but de lire un fichier .csv contenant une liste de clients qui vivent en Californie, 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_feature400 et permettra aux équipes de développement de tester, filtrer et mapper tous types de 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 scénario de test a pour but :
  • de lire des fichiers de données d'entrée (composants tFileInputDelimited),

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

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

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

  • de 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 exécuté une fois que le jeu de données a été défini dans la vue Test Case et qu'un groupe de contextes spécifique (appelé Test) a été défini dans la vue Context. Le jeu 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 l'équipe de développement a conçu les tests d'intégration localement dans le Studio Talend, ces tests doivent être automatisés à l'aide d'outils d'intégration continue, comme les systèmes de build. Pour plus d'informations, consultez Construire et déployer.

Cette page vous a-t-elle aidé ?

Si vous rencontrez des problèmes sur cette page ou dans son contenu – une faute de frappe, une étape manquante ou une erreur technique – dites-nous comment nous améliorer !