De nos jours, l’intégration continue est sur toutes les lèvres. Il faut de plus en plus automatiser les chaînes de livraisons pour diminuer le nombre d’actions effectuées de main humaine, dans la chaîne de construction et de livraison de nos applications.

Mais qu’est-ce exactement que l’intégration continue ?

Et comment un outil comme Ranorex Studio peut y trouver sa place ? Nous allons essayer dans les quelques lignes suivantes d’apporter une réponse à ces deux questions.

Qu’est-ce que Ranorex Studio ?

Ranorex Studio, abrégé en Ranorex, est un outil d’écriture et d’exécution de tests automatisés. Il fonctionne sur un environnement Windows uniquement  (à l’heure où cet article est écrit, il n’est cependant pas encore compatible avec Windows 11). Il permet notamment d’automatiser vos tests d’application Web bien sûr, mais également mobiles ou desktop. Les fonctionnalités les plus importantes, pour ce qui nous intéresse dans cet article, sont sa facilité de connexion avec la plupart des outils de chaînes d’intégration et de livraison continues, ainsi que la possibilité de configurer des profils de lancement, pour finir par un format propriétaire, facilement lisible, de rapport de test… Nous y reviendrons plus tard.

Qu’est-ce que l’intégration continue ?

L’intégration continue est un ensemble de pratiques qui, dans le cadre de la plupart des méthodologies agile et dans les architectures dites « DevOps », permettent de garder une traçabilité et une continuité dans la qualité du produit qui sera livré au client.

Grâce à ces bonnes pratiques, il est possible de détecter plus tôt les erreurs qui pourraient se glisser dans le code et de les corriger très tôt dans le processus de conception de l’application. Cela diminue donc les risques qu’une erreur mettant en péril le fonctionnement de l’application arrive jusqu’à l’utilisateur. L’idéal est donc que les tests automatisés viennent s’ajouter dans cette chaîne d’intégration continue de manière à avoir les résultats des tests aussi rapidement que possible lorsque des fonctionnalités sont livrées sur le gestionnaire de code source.

Comment un outil d’automatisation de test comme Ranorex trouve sa place dans une chaîne d’intégration continue ?

Un des objectifs d’une chaîne d’intégration continue automatisée est de diminuer le temps passer à attendre, par les développeurs et les testeurs, la construction de l’application pour les premiers et le passage des tests pour les seconds. Pour se faire, on utilise donc un outil dit d’intégration et de livraison continues (ou CI/CD) pour automatiser ses tâches qui par le passé étaient chronophages. Ranorex, comme je vous le disais précédemment, trouve parfaitement sa place dans ce genre d’outils. Si nous prenons un outil couramment utilisé sur les projets comme Jenkins, Ranorex s’y intègre parfaitement et très simplement. Pour lancer vos tests, qu’il s’agisse de les lancer sur une machine distante physique ou virtuelle, ou encore sur un container, il suffit qu’un « agent » Ranorex et qu’un « agent » Jenkins soient déployés sur la machine sur laquelle les tests seront lancés. Ensuite, dans Ranorex il existe ce que nous appelons une configuration de build, qui permet de planifier le lancement des tests en fonction de la configuration choisie. Il ne restera donc plus lorsque vous envoyez votre code vers votre gestionnaire de code source de penser à joindre, dans le projet de votre application, un fichier que nous appellerons un JENKINS_FILE. Dans celui-ci, vous préciserez tout ce que votre Jenkins doit connaître pour construire votre solution. Vous faîtes de même sur votre projet Ranorex s’ils sont dans deux projets différents.

Dans le JENKINS_FILE de votre projet de test, vous précisez la configuration de build que vous souhaitez lancer et votre outil d’intégration continue s’occupera de tout par lui-même. Il lancera dans un premier temps la construction de votre solution avec l’ensemble de vos paramètres, puis lancera de la même manière vos tests automatisés et génèrera selon votre demande une archive avec les rapports de tests à disposition directement sur la machine où les tests auront été lancés, les rapports de tests au format « .rxzlog ».

 En conclusion, nous voyons que le déploiement d’une application de la construction jusqu’à la fin des tests peut se faire au sein CI/CD.

Il n’y a plus de raisons d’hésiter des milliers de projets y sont déjà passés, à quand le vôtre? Et la prochaine étape sera peut-être l’intégration de la containérisation dans votre CI/CD avec Docker et Kubernetes. A suivre…

                                                     Credits: @Nicolas Briet, Expert outils de Test et Devops