Un cadre de test automatisé utilisant ProcessMaker + Selenium + Github

À l'ère moderne de la construction de logiciels, toutes les équipes de développement de logiciels bien gérées devraient comprendre l'intérêt des tests. Les nouvelles applications devraient être construites avec une couverture de tests unitaires presque parfaite pour les tests automatisés. En outre, les tests fonctionnels par navigateur devraient être entièrement automatisés en utilisant des outils à source ouverte comme Selenium afin de saisir les modèles connus d'interaction humaine.

Les défis de l'intégration des tests fonctionnels dans les IC/CD

Les cas d'utilisation fonctionnels ont tendance à évoluer dans le temps et à changer régulièrement à mesure que les cas d'utilisation d'une suite logicielle se développent et évoluent. En conséquence, de nombreuses entreprises ont du mal à faire fonctionner un ensemble de tests au sélénium en constante évolution dans le cadre d'une chaîne de tests et de déploiement automatisée. 

En particulier, dans le monde actuel des logiciels SaaS, de nombreuses applications SaaS à plusieurs locataires comportent des suites entières de tests au sélénium qui doivent être effectués avant qu'un nouveau locataire ne soit mis à disposition. Ces tests doivent être effectués dans le cadre de la procédure automatisée de mise à disposition des locataires.

La réalité, cependant, est que la plupart des sociétés SaaS ne le font pas. Le résultat se traduit par des incohérences constantes lors de l'approvisionnement des nuages par les locataires ou les entreprises privées.

Alors, quelle est la solution ? 

Même si le sélénium est un moyen efficace et populaire d'automatiser les tests par navigateur, les organisations ont besoin d'un moyen d'automatiser l'inclusion de bancs d'essai au sélénium correctement versionnés dans les pipelines de déploiement.

ProcessMaker est une solution idéale pour automatiser un pipeline de déploiement et d'approvisionnement de tests de sélénium directement à partir de leurs dépôts à Github. Voyons comment cela peut être fait.

Suites de tests sur le sélénium à Github

Imaginez un instant une entreprise qui possède un seau de tests automatisés au sélénium, stockés sous forme de fichiers Python dans GitHub. Ces fichiers python doivent être exécutés à chaque fois avant qu'un nouvel espace de travail locataire ou une installation de cloud privé ne soit mis à disposition. Si l'un des cas de test échoue, nous voulons nous assurer que le provisionnement ne se poursuivra pas.  

En outre, nous reconnaissons que les cas types changeront et évolueront constamment. Dans ce cas, nous avons plusieurs équipes qui veulent pouvoir contribuer aux tests d'une repo versionnée, et nous voulons être sûrs que nos tests de sélénium sont toujours effectués en utilisant la dernière version stable et approuvée des tests.

Dans ce cas, les tests seront effectués avec du sélénium. Bien entendu, Selenium est un outil open-source extrêmement populaire qui est utilisé par les développeurs du monde entier. Avec Selenium, vous pouvez automatiser chaque tâche de votre navigateur. De plus, il est compatible avec Chrome, Firefox, Safari, IE et Mozilla. 

Dans ProcessMaker, nous avons créé un workflow de déploiement qui extrait de github le harnais de test au sélénium approprié, l'exécute, vérifie les problèmes et, si tout réussit, appelle une fonction Lambda afin de déployer un nouveau serveur AWS avec le code vérifié.

ProcessMaker nous donne une représentation visuelle du flux de travail, une capacité à suivre les performances, le temps et les erreurs. Voici à quoi ressemble le flux de travail pour une entreprise qui utilise actuellement ProcessMaker de cette manière :

La flexibilité est la clé de la gestion des tests. ProcessMaker permet de regrouper et de remanier facilement les cas de test afin d'améliorer la maintenabilité tout en réduisant la complexité et la duplication. Grâce aux outils faciles à utiliser de ProcessMaker, vous pouvez réduire le temps d'exécution des tests et même exécuter plusieurs tests en parallèle. 

En utilisant ProcessMaker, les tests de sélénium sont extraits du dépôt de code et exécutés par une série de tâches de script dans ProcessMaker qui fait passer le test par une image de docker de sélénium et stocke ensuite les résultats du test dans la requête. 

Une partie de la beauté de ProcessMaker est qu'il gère les données comme un objet Json très léger, non structuré et facile à comprendre. Pendant la durée de vie d'une requête (une instance de processus), ce Json peut recevoir des données provenant de nombreuses sources différentes. Dans le cas des tests au sélénium, les résultats renvoyés par les tests au sélénium sont simplement ajoutés dans l'objet Json. Ensuite, en fonction de la manière dont notre flux de travail est censé fonctionner, nous pouvons utiliser des règles ou des passerelles externes pour évaluer les résultats et modifier ce qui se passe dans le flux de travail.

Par exemple, ProcessMaker peut être configuré pour exécuter des actions de suivi en fonction des résultats des tests qui renvoient des résultats == "succès". A la passerelle, on évalue la variable des résultats. Si les résultats sont positifs, nous avons alors configuré le flux de travail pour appeler un nouveau script de dégustation qui est la fonction lambda que nous utilisons pour faire tourner un nouveau locataire (espace de travail). Si les résultats indiquent un "échec", nous ne procéderons pas à la rotation du locataire. Dans ce cas, nous pouvons afficher les détails de l'échec dans un canal Slack ou via un e-mail en utilisant les connecteurs de ProcessMaker pour Slack ou Email.  

En utilisant ProcessMaker comme harnais de test de cette manière, nous pouvons tester toute application personnalisée avant de la mettre en œuvre sur un serveur pour un client. Nous obtenons ainsi une flexibilité dans les flux de travail complexes et la possibilité d'adapter et de lancer des tests à la demande. 

Exécution du processus via l'API ProcessMaker

Comme l'exécution des processus peut se faire par le biais d'appels API, l'utilisation de ProcessMaker peut faire partie de vos pipelines CI/CD. Si un environnement est déployé ou mis à niveau, le pipeline CI/CD peut exécuter un appel API REST contre ProcessMaker pour commencer à exécuter une suite de tests basée sur la charge utile de la demande d'appel API.

En utilisant un processus de CI/CD, vous obtenez une clôture plus rapide des problèmes car vous avez une identification et des corrections de bugs plus rapides. De plus, la planification et l'exécution des tests sont maintenues de manière cohérente. Aucune compétence technique n'est requise. Le déploiement est plus facile et plus rapide, avec pratiquement aucun temps d'arrêt. Des applications de meilleure qualité peuvent être créées parce que vous avez plus de temps pour vous concentrer sur la convivialité, la sécurité, l'exploration et les tests de performance. Un retour d'information continu améliore également la qualité globale.

Exécution des sous-processus

Un processus simple peut être conçu pour exécuter un seul test au sélénium et renvoyer le résultat. Une suite de tests peut être un processus parent qui boucle l'exécution d'une suite de tests définie et prend des décisions plus complexes en fonction des résultats.

À la base, le moteur de flux de travail de ProcessMaker est hautement personnalisable. Vous pouvez suivre les tests en toute transparence. Voici quelques-uns de ses avantages :

• Une meilleure efficacité des tests
• Diminution des coûts de maintenance
• Couverture de test optimisée
• Peu d'intervention manuelle nécessaire
• Réutilisation du code
• L'expertise en matière d'automatisation des tests n'est pas nécessaire

Tests au sélénium en conteneur avec tâches de script

Les tâches de script sont exécutées dans des conteneurs Docker pendant le cycle de vie de ce script. Nous pouvons exploiter l'image de Sélénium dans le docker afin d'exécuter un test avec isolation en bac à sable. Nous pouvons également personnaliser l'image Docker pour qu'elle hérite de l'image de base du sélénium, puis fournir un échafaudage pour charger le test et l'exécuter, ce qui renvoie les résultats dans un format JSON approprié, comme l'attend ProcessMaker.

Pourquoi ProcessMaker aime-t-il JSON ? Eh bien, pour commencer, JSON est plus lisible et plus compact que XML, ce qui facilite le travail avec des systèmes complexes. Comme JSON utilise moins de données que XML, l'analyse du logiciel est beaucoup plus rapide. JSON facilite également la mise en correspondance temporelle avec les objets du domaine. La structure des données cartographiques de JSON est également facile à comprendre. En outre, JSON assure la correspondance des objets et des codes.

Mise à l'échelle

L'exécution des suites de tests se fait à la demande et peut être configurée comme un déploiement dans un seul environnement ou à grande échelle (mises à niveau dans plusieurs environnements). Vous pouvez facilement étendre l'exécution des suites de tests en utilisant l'infrastructure de mise à l'échelle automatique de ProcessMaker.

Stockage des suites de tests sous forme de code

L'objectif est de stocker la définition d'une suite de tests sous forme de fichier JSON dans un dépôt de code GitHub. Le fichier JSON définira les tests à exécuter, chaque test étant également stocké dans le dépôt de code. Cette utilisation des dépôts de code git pour stocker les suites de tests nous permet d'exploiter les ramifications et autres caractéristiques de git pour contrôler et gérer les suites de tests. Cela permet également d'utiliser l'exécution de ces tests, sans utiliser ProcessMaker, localement à des fins de développement et de débogage.

Alors pourquoi utiliser GitHub ? Honnêtement, parce que le wiki de GitHub et le suivi des problèmes nous donnent le retour d'information et la documentation approfondie dont nous avons besoin. De plus, vous pouvez suivre les révisions sur plusieurs versions. De plus, en termes de contrôle des versions, nous aimons les possibilités de ramification de Git. Grâce aux fonctions de ramification, vous pouvez travailler dans un environnement isolé pour chaque changement que vous devez apporter à votre base de code. Comme GitHub utilise un système de contrôle de version distribué, chaque personne travaillant sur le même projet peut avoir son historique complet sauvegardé dans son propre dépôt localisé. De plus, si deux contributeurs apportent des modifications au même fichier, GitHub combinera intelligemment les modifications. Il est également assez facile de revenir à une version spécifique. Dans l'ensemble, cela permet un cycle de publication plus rapide et GitHub fonctionne de manière transparente avec les environnements CI/CD.

Conclusion

Lorsque vous choisissez un outil de test automatisé, vous devez en rechercher un qui soit agile et qui offre un support pour un large éventail de langues et d'applications. Cela permettra à votre équipe de contribuer à vos cycles de test sans avoir besoin de compétences techniques.