Lecture 11 minutes

Chez Synolia, nous faisons beaucoup de tests à la main lorsque nous développons de nouvelles fonctionnalités ou que nous corrigeons des bugs présents sur une plateforme.

Ces tests sont réalisés à la fois par les équipes Synolia (développeurs/développeuses et chefs/cheffes de projet) et par les équipes côté client :

• En local, lorsque nous avons fini de développer notre fonctionnalité.
• En intégration, lorsque nous déployons cette nouvelle fonctionnalité ou la correction d'un bug.
• En pré-production, une fois l'intégration validée par Synolia et le client.
• En production, une fois le développement en pré-production validé par Synolia et le client.

Ils peuvent donc vite devenir chronophages. Et, parfois, il n'y a pas vraiment de valeur ajoutée à ce qu’ils soient réalisés par des actions humaines, surtout quand ceux-ci sont identiques et redondants (comme les tests de non régression par exemple). Ainsi, optimiser les tests par le biais de l'automatisation s'avère très intéressant.

Conscients que les tests automatisés sont la réponse évidente à ces situations, nous avons fait l’essai pour un projet client ayant une très forte volonté, et un budget alloué à ce sujet pour fiabiliser les flux entre l'ERP et Adobe commerce afin d’éviter les régressions lors de corrections ou ajouts de nouvelles fonctionnalités.

Le besoin

D’abord, nous avons réfléchi à la manière dont nous pourrions optimiser les tests. Et les automatiser nous a semblé être pertinent. Ceci afin de verrouiller les développements et de s'assurer que, lorsque nous apportons une modification au code au niveau des flux de données entre l'ERP et Adobe commerce, ceux-ci ne cassent pas les échanges entre les deux entités.

Par ailleurs, le client souhaitait pouvoir lancer les tests lui-même, à la demande, simplement à partir d'une interface. Il fallait aussi que nous puissions les lancer via notre CI (Jenkins) lors d'un déploiement.

Enfin, il fallait que nous puissions lancer des scénarios de bout en bout - du passage de commande jusqu'à la demande de retour sur un produit avec des tests qui dépendent donc les uns les autres. Et il s’agissait là de la principale difficulté.

La démarche pour optimiser les tests

Nous avons vérifié la faisabilité de ce projet d’automatisation via la mise en place de plusieurs POC (Proof Of Concept). Ceci pour montrer les résultats au client et prendre une décision collective sur la marche à suivre.

Étude de la solution standard de magento MFTF

Tout d'abord, nous nous sommes intéressés à la solution native que propose Adobe commerce, à savoir MFTF pour Magento Functional Testing Framework.

MFTF est un framework de tests créé par Adobe Commerce pour dérouler des tests fonctionnels sur la plateforme de façon simplifiée en apportant des outils pour, par exemple, créer simplement des commandes, des clients, des produits, etc.

Pour en apprendre plus sur MFTF, ce lien peut vous être précieux.

Mise en place d'un POC sur MFTF

Nous nous sommes donc lancés sur l'installation de MFTF en local sur un Adobe Commerce standard pour découvrir le fonctionnement de cet outil. La première difficulté rencontrée a été l'installation de la suite qui n'est pas forcément des plus évidentes. En effet, il faut installer un serveur selenium ainsi que des webdrivers (celui de chrome par exemple) en local pour pouvoir lancer les tests qui utilisent un navigateur. Il faut également avoir une version de Java et réaliser plusieurs configurations (dont on passera les détails ici, mais que vous pouvez retrouver dans cette documentation si le sujet vous intéresse).

La documentation de MFTF est claire, mais la tâche reste tout de même compliquée à mettre en œuvre, surtout si plusieurs développeurs sont amenés à travailler sur ces tests en local. Ils doivent tous passer par l'installation de leur environnement de tests afin de pouvoir en commencer l’écriture.

La deuxième difficulté liée à toute cette installation est celle de la mise en œuvre dans la CI, pour pouvoir lancer des tests automatiquement lors des déploiements. En effet, il faut disposer d’un serveur pour installer tous les outils nécessaires au lancement de ces tests, comme décrits pour les machines locales, et réaliser toutes les configurations nécessaires. Impossible dans notre cas car le client ne disposait pas d’un tel environnement. Il aurait fallu qu’il investisse dans un environnement supplémentaire. De plus, le client n'aurait pas eu la possibilité de lancer des tests manuellement, à la demande. Il aurait fallu développer un système en complément, afin de lancer des tests via le BO d'Adobe Commerce.

Optimiser les tests : l'obstacle des tests isolés

Enfin dernière difficulté, la philosophie de MFTF est de faire des tests isolés les uns des autres avec suppression des données entre ceux-ci. Par exemple, si nous devions réaliser un premier test qui consiste à créer une commande et vérifier les montants associés à cette commande en BO, et un deuxième qui consiste à expédier la commande et vérifier les montants en BO, nous aurions dû créer deux tests distincts :

• Un premier pour créer une commande, vérifier les montants en BO et supprimer la commande à la fin de notre test.
• Un deuxième pour recréer la commande, l’expédier puis vérifier les montants en BO.

Ce mode de fonctionnement n’était pas souhaité car le but était justement de vérifier la consistance des données de la commande entre les différentes étapes du test en utilisant toujours la même commande en entrée.

Étude avec Ghost Inspector et Synolia Sync

Ghost inspector est un outil permettant de réaliser des tests automatiques via un navigateur web (Chrome ou Firefox). Le tout grâce à un plugin qui permet d’enregistrer directement nos clics de souris ou nos entrées de clavier lorsque l’on navigue sur un site.

Il n’y a donc rien à installer, si ce n’est un plugin sur le navigateur pour pouvoir créer des tests. Ils peuvent ensuite être appelés via API, à la demande. Nous pouvons également ajouter des variables à ces tests afin de les factoriser. Ces variables sont ensuite passées via l’API selon les cas de test.

Si vous souhaitez plus d’informations sur Ghost inspector, nous vous invitons à visiter le site de l'outil. Et également cet article de Synolia sur le sujet.

Étude avec Synolia Sync

Synolia Sync est un module Adobe Commerce créé par Synolia. Son objectif : écrire simplement des suites d’actions à réaliser via des commandes CLI en créant une séquence dans un fichier XML.

Le client ayant déjà une licence Ghost inspector et le module Synolia Sync installé sur sa plateforme, nous nous sommes penchés sur l’utilisation de ces deux composants afin de lancer, à la demande et de façon séquentielle, plusieurs tests Ghost inspector à la suite en vue de dérouler un scénario complet de A à Z.

L’idée ici est donc d’écrire des tests Ghost inspector et de les lancer les uns à la suite des autres avec Synolia Sync. Entre ces tests, nous avons également des étapes qui se chargent de lancer des flux spécifiques au projet sur Adobe Commerce. L'objectif est de simuler le dialogue entre l’ERP et Adobe Commerce ou vérifier des fichiers générés à certaines étapes clés. Cela permet de créer de vrais scénarios, dans le contexte de l’application.

Cette solution à l’avantage de se lancer simplement via notre CI sur Jenkins ou via l’interface en BO, ce qui répond au besoin du client.

Nous pouvons également nous servir de la commande générée au tout début du scénario et la faire passer par toutes les étapes du test en la réutilisant à chaque fois, et ainsi vérifier le bon déroulement du scénario à chaque étape.

Mise en place d'un POC sur Synolia Sync + Ghost Inspector

La mise en place du POC avec Ghost inspector et Synolia Sync consiste à l’écriture d’un scénario de test basique de passage de commande et de retour du produit.

Pour cela, nous avons mis en place un flux sync pour lancer à la fois des tests réalisés sur Ghost inspector et d'autres flux sync propre au projet. Puis nous avons mis en place des étapes pour comparer les fichiers cibles (fournis par le client) avec les fichiers générés par le test.

Voici les étapes qui ont été écrites pour notre scénario de test :

Le lancement d’un tel test qui est assez complet dure environ 15 minutes. Bien sûr, en cas d’échec sur l’une des étapes, le flux s’arrête et envoie une erreur formatée pour consultation dans des logs dédiés, dans l'interface de notre module sync, sur un channel Slack dédié, ou même sur ces trois canaux en même temps. Cela permet de voir où le test a échoué... Et de savoir si un développement aurait éventuellement cassé le workflow de commande.

Optimiser les tests : conclusion

Chacune des solutions proposées ici possèdent forces et faiblesses. Nous avons ainsi opté pour la deuxième solution car nous trouvions que celle-ci était beaucoup plus simple à mettre en œuvre. Et surtout, celle-ci répondait parfaitement au besoin initial du client.

Elle est également plus aisée concernant son développement. En effet, les tests Ghost inspector couplés à Synolia Sync sont beaucoup plus simples à mettre en place que des tests avec MFTF.

Nous pensons que la mise en place de tels tests va faire gagner un temps non négligeable. Aux équipes Synolia d'abord, mais surtout aux équipes côté client. De quoi s'assurer d'un niveau de qualité bien meilleur sur la non régression des flux entre Adobe Commerce et l’ERP du client.