L’automatisation des tests de la refonte de l’API, dans le cadre de la migration vers le cloud, était primordiale pour l’entreprise. L’avantage était que j’étais présent dès le début et que je disposais d’un accès de « debug » direct à cette nouvelle API en exécutant un proxy localement via gcloud.

Le but de ces tests était de s’assurer que chaque nouveau champ était requêtable individuellement et aussi en combinaison avec d’autres. Pour exploiter pleinement les avantages de l’automatisation, le endpoint utilisé fonctionnait en mode « dryrun », c’est-à-dire que l’API vérifiait uniquement si la requête était possible sans l’exécuter réellement, évitant ainsi toute facturation sur le cloud.

Au fil du temps, de nouveaux champs et paramètres étaient ajoutés à l’API, rendant les tests en constante évolution. Cette API privée était destinée à être appelée par une autre API publique pour les clients et l’interface utilisateur (UI). Il était donc nécessaire d’étendre les tests à cette nouvelle API en gérant également le mapping des noms des champs.

Une approche structurée


La solution la plus simple et logique a été de créer un projet dédié au recensement des champs sous forme de constantes, avec :

Ce projet était exporté sous forme de package NPM, réutilisable dans différents projets Cypress ou Playwright.

Grâce à cette structure, j’étais capable de créer des combinaisons aléatoires robustes avec la totalité des champs disponibles.

Gestion des spécificités

Chaque projet avait ses spécificités. Le plus complexe concernait l’API privée, car elle comportait bien plus de champs et de cas d’usage, notamment des champs réservés aux équipes internes pour le reporting ou le suivi d’analyse.

Pour réaliser ces tests, il fallait générer un JSON unique à chaque test en ajoutant de nombreux paramètres aléatoires :

  • Un outputName unique, mélangeant les lettres du champ d’origine.
  • Un ordre de tri.
  • Des dates et formats de dates aléatoires.
  • Des filtres aléatoires en fonction du cas d’usage.
  • Un format de fichier (CSV ou XLSX) avec un séparateur aléatoire parmi ceux de la liste ISO 8859.

Tout cela tout en gérant les cas particuliers et les incompatibilités.

En parallèle, pour certains tests, il fallait forcer le type de champ demandé pour vérifier les différents niveaux de requête générés par le Query Composer.

Tests additionnels et intégration continue

J’ai également ajouté des tests non passants pour valider les corrections des bugs identifiés (tickets)

Initialement réalisés avec Cypress, ces tests API ont ensuite été migré vers Playwright et exécutés quotidiennement sur GitLab CI. De plus, l’équipe de développement me demandait régulièrement de lancer ces tests après chaque déploiement d’une nouvelle version de l’API, en particulier du Query Composer, qui faisait également l’objet de tests dédiés.

L’équipe s’appuyait énormément sur ces tests.

Bilan

Au total, plus de 1 150 tests ont été réalisés :

  • 815 champs testés individuellement.
  • Des tests combinatoires.

Les tests individuels comprenaient entre 1 et 10 appels API, selon le nombre de cas d’usage disponibles pour chaque champ.

Grâce à la parallélisation au niveau de GitLab et des workers de Playwright, l’ensemble des tests s’exécutait en 15 minutes en moyenne, notamment grâce à l’étape d’optimisation des images Docker. Si le package du projet n’avait pas changé entre deux exécutions, la création et l’installation de l’image étaient facultatives, ce qui réduisait encore le temps d’exécution.