Mutualiser la session Spark pour vos tests unitaires

Et gagner en temps d’exécution !

Aujourd’hui on se retrouve pour une petite astuce sur le sujet de l’optimisation de vos tests unitaires en Spark/Scala. Concrètement, cet article vient du fait que je me suis rendu compte qu’au fur et à mesure du développement de mes tests unitaires (et de la croissance sans fin de leur nombre…), certains prenaient un temps fou à s’exécuter.

Une session Spark par fichier

Mon principal problème résidait finalement dans le fait que je déclarais une nouvelle session Spark dans chacun de mes fichiers de tests :

La réalité, c’est que ce petit bout de code va démarrer, pour chacun de vos fichiers de tests, une nouvelle session Spark. Même avec la fonction getOrCreate, certaines actions de démarrage vont s’exécuter. Au lancement des tests, j’ai pu mesurer que le lancement de la SparkSession me prend entre 15 et 30 secondes. En multipliant cela par le nombre de fichiers de tests que possède l’application, on arrive à des durées de plus en plus importantes (et frustrantes 😤) jusqu’à obtenir l’inacceptable alors qu’aucun test en lui même ne s’est réellement exécuté !

Alors, comment on accélère tout ça ?

Vous l’aurez deviné, on va faire exactement ce qui est dans le titre de cet article ! Ce que je propose, c’est d’encapsuler la session Spark dans un trait Scala et d’étendre cet objet dans chacune de vos classes de tests :

Maintenant que votre session Spark est étendue sur tous vos fichiers de tests (class MyClass extends SparkSessionUtils), elle ne démarrera qu’une seule fois puis sera partagée dans toutes vos classes ! C’est vraiment du temps de gagné 👌 !

Autre astuce permise par cette méthode : vous pouvez donner à votre session Spark partagée les configurations que vous souhaiter avoir, directement dans votre Trait. Au revoir la duplication de code 👼 ! Par exemple, dans le code ci-dessus, vous pouvez voir que j’ai spécifié le niveau de log de Spark à ERROR, cela permet de n’afficher que très peu de messages lors de l’exécution des tests unitaires. C’est personnel, mais je préfère avoir le moins de messages de logs possibles, le moins de “bruit” et n’avoir à la fin que les informations essentielles à mon programme.

J’espère que cette petite astuce vous aura plu.

Je vous dis à bientôt dans un prochain article !👋