Comment tester l'étape batch de Spring qui lit depuis la base de données et écrit dans un fichier ?

Question

J'aimerais savoir quelle serait la meilleure approche pour tester le scénario ci-dessous dans une tâche Spring Batch :

• Un travail qui consiste en deux étapes :

1) La première étape lit à partir d'une base de données en utilisant un fichier ItemReader ( from apache kudu using impala ) et écrit dans un fichier le contenu généré par la requête.

• Ce itemReader a un rowMapper qui crée un objet complexe à partir du jeu de résultats. Son site itemWriter fait juste un toString (which in fact is a JSON representation) de cet objet complexe.

2) La deuxième étape lit à partir du fichier généré par le programme step 1 et le traite. Après avoir traité tous les fichiers, tout est écrit dans un nouveau fichier.

• El itemReader lit le fichier à partir de step 1 en utilisant un jsonLineMapper Il traite ensuite les nouveaux objets complexes générés par le mappeur et les écrit dans un nouveau fichier.

Ensuite, l'auditeur de la tâche télécharge les deux fichiers dans S3.

J'ai besoin de ce flux de travail car la première étape génère l'échantillon nécessaire à la deuxième étape. Et si un jour j'ai besoin de tester uniquement la deuxième étape, je peux utiliser un ancien échantillon de la première étape, car la base de données varie au fil du temps et sans lui, je ne pourrais peut-être pas générer le même échantillon de l'exécution de deux jours auparavant.

La première étape est la plus difficile à tester, mais je voudrais tester les deux étapes de la manière suivante :

1) De step 1 Je dois vérifier que la syntaxe de la requête est correcte. Je dois également vérifier que le jeu de résultats de la base de données génère des objets corrects via la fonction rowMapper . Le contenu du fichier de itemWriter est correct (correct means that is expected) .

2) Cette deuxième étape est plus facile à tester, car je pourrais commencer avec un fichier prédéfini. Il devrait tester que la lecture du fichier en utilisant la fonction jsonLineMapper est fait correctement. La partie traitement est testée à part, mais je pourrais suivre un flux de travail simple, et le fichier final a le contenu attendu.

Mon idée pour tester ce scénario était :

1) Afin de vérifier que la syntaxe de la requête est correcte, j'ai besoin d'un constructeur de requêtes (j'ai cherché sur Google et j'ai trouvé des bibliothèques telles que jOOQ mais je ne veux pas ajouter une bibliothèque externe juste pour construire une requête de chaîne). Après avoir vérifié que la requête est correcte, je devrais peut-être mock la base de données et retourner un objet complexe prédéfini et l'écrire dans le fichier. Le problème est que si la requête renvoie une colonne manquante, l'objet ne serait pas correct, et le test devrait échouer, donc si je renvoie un objet prédéfini, je ne saurais jamais quel est le retour de la requête.

Comme vous pouvez le voir ici, le problème réside dans la validation de la requête, car si la requête est correcte, je peux tester la fonction rowMapper et le fichier final.

2) Pour cette étape, j'ai pensé que la meilleure approche serait de disposer d'un fichier prédéfini avec un contenu correct à partir de step 1 et vérifier simplement que le contenu du fichier final correspond à ce que j'attends. Je pense qu'il est facile de tester cette étape.

Y a-t-il un meilleur moyen ou une meilleure approche pour tester ce scénario ?

Merci !

Answer 1

Pour l'étape 1, je vous recommande d'utiliser une base de données intégrée pour insérer quelques lignes, exécuter votre travail et vérifier que le fichier généré est correct. Cela vous permet d'avoir le contrôle sur les données de test afin de valider votre requête et le résultat attendu dans le fichier. Vous pouvez trouver un exemple ici : https://docs.spring.io/spring-batch/4.0.x/reference/html/testing.html#endToEndTesting . Spring Batch fournit le AssertFile.assertFileEquals pour tester si deux fichiers sont égaux. Cela peut vous aider à valider la sortie de l'étape 1 par rapport à un fichier attendu.

Pour l'étape 2, vous pouvez créer des fichiers valides/invalides (qui peuvent être le résultat de l'étape 1) et les utiliser comme entrée pour tester l'étape 2. Le problème est que si le résultat de l'étape 1 change, ces fichiers ne seront plus valides pour tester l'étape 2 (il s'agit donc d'un coût de maintenance dont vous devez être conscient).