Les appareils iOS revendiquent toujours une part importante du marché mobile, prenant jusqu’à 22 % des ventes dans le monde. Comme de nombreux clients dévoués reviennent pour les nouveaux produits Apple, il y a également une grande demande pour les applications iOS. Dans cet article, nous allons voir comment assurer la qualité des applications iOS en s’efforçant d’utiliser les meilleures pratiques à l’aide des outils Appium, Cucumber et Serenity.

Structure

Le Page Object Model est l’une des meilleures approches de test que les ingénieurs AQ peuvent appliquer à un projet d’automatisation des tests. C’est une telle façon de structurer le code dans un projet d’automatisation qui améliore la qualité et la lisibilité du code, la maintenance des tests et en plus de cela, c’est un excellent moyen d’éviter le chaos. L’idée de base derrière elle vient de garder toutes les références aux éléments mobiles et aux méthodes effectuant des opérations sur eux dans un fichier de classe pour chaque page ou écran de l’app (ou page web pour les applications web non natives).

Quels sont les avantages de cette approche, vous pouvez vous demander ? Tout d’abord, elle rend l’automatisation vraiment simple. Fondamentalement, il s’agit de trouver des éléments dans notre application iOS via l’inspecteur, puis d’effectuer des opérations sur eux. Un autre avantage principal est la structure cohérente du projet qui permet à quiconque de s’y retrouver rapidement.

Prenons l’exemple d’une app qui contient des recettes. Elle montre le livre de recettes par défaut avec des recettes de base au démarrage, qui sera notre première page. De là, un utilisateur peut naviguer vers n’importe quelle recette disponible, marquant ainsi une deuxième page. En plus de cela, l’application permet également de parcourir d’autres livres de cuisine ou d’acheter des livres premium, ce qui en fait la troisième page et par conséquent – un fichier d’objet de page.

De même, nous devrions créer des fichiers de définition d’étape correspondants. Ce n’est pas une pratique obligatoire, mais garder toutes les définitions d’étapes à un seul endroit provoque un chaos inutile.

Lorsque vous créez vos pages et vos fichiers de classe de définition d’étape, il est conseillé de choisir des noms qui sont liés à la page (écran d’app) dont le contenu vous allez travailler. Nommer ces fichiers d’après une fonctionnalité ou un scénario peut sembler correct à première vue, mais au fur et à mesure que le projet se développe, vous remarquerez de plus en plus de désordre dans sa structure. L’adoption de la convention de dénomination des pages permet à toute personne impliquée dans le projet de se familiariser immédiatement avec celui-ci et de commencer à collaborer en un rien de temps. Une telle pratique contribue également à la réutilisation du code – qu’il s’agisse de définitions d’étapes ou de méthodes/fonctions.
Contrairement aux fichiers de définition d’étapes et d’étapes mentionnés, les fichiers de fonctionnalités Cucumber doivent être nommés d’après une fonctionnalité qu’ils vérifient. Astucieux, n’est-ce pas ? Et encore une fois, les structurer en répertoires nommés en relation avec un champ particulier de l’application testée rendra la structure plus significative.
Le concept de base de Serenity est d’être une « documentation vivante ». Par conséquent, donner des noms appropriés aux scénarios de test et aux fichiers de fonctionnalités aide l’équipe et les parties prenantes à mieux comprendre les rapports et l’ensemble du projet.

Un autre ingrédient élargissant les avantages du Page Object Model dans le projet d’automatisation des tests est PageFactory. C’est un outil qui vous aide à réduire le travail de codage et à mettre facilement des localisateurs MobileElements dans le code, en utilisant la notation @FindBy. A partir de là, trouver des éléments pour qu’Appium interagisse avec eux dans les tests est beaucoup plus simple.

Assertion

L’exécution de tests via Appium peut être très consommatrice de ressources. Pour faciliter la tâche de votre machine MacOS qui exécute des tests sur votre appareil iOS, assurez-vous de ne pas affirmer constamment la visibilité de tous les objets d’une page. Cette pratique augmente considérablement le temps d’exécution des tests, ce qui n’est généralement pas la chose la plus souhaitable.

De plus, lorsque vous devez vérifier si un élément est visible, activé, cliquable, ou quoi que ce soit entre les deux – essayez d’éviter de localiser les éléments mobiles en utilisant Xpath. Le conseil de l’inspecteur d’Appium a un point valable ! Vous devriez faire votre possible pour convaincre l’équipe de développement de faire un effort supplémentaire et d’attribuer des ID et des noms uniques aux éléments de l’application. Cela rendra non seulement les tests d’automatisation plus faciles et plus rapides, mais aussi votre travail de testeur plus efficace, ce qui aura pour effet d’augmenter la qualité globale du produit. Et c’est pour cela que nous sommes là. Sans oublier que la maintenance des tests (par exemple, le passage à différents localisateurs si nécessaire) deviendra beaucoup plus agréable.

Comprendre les étapes

Un autre aspect de la mise en place de ce type de projet se résume à tirer parti de Cucumber et à utiliser le langage Gherkin.

Gherkin met en œuvre une approche directe avec la notation Given, When, Then avec l’aide des And et But supplémentaires qui semblent assez faciles à utiliser. Vous pourriez écrire à peu près tout ce que vous voulez dans les étapes de test de vos fichiers de fonctionnalités. En fin de compte, les méthodes appelées vont exécuter des actions.

Mais la raison de l’utilisation de l’approche Behavior Driven Development et de Cucumber lui-même est de permettre aux personnes non techniques impliquées dans le projet de comprendre ce qui se passe dans le champ des tests. En outre, l’écriture de scénarios de test en mode Given/When/Then peut également jouer en votre faveur. De telles descriptions de test de haut niveau fournies par le client ou l’analyste métier vous feront coder en un rien de temps, à condition qu’elles soient écrites correctement. Voici quelques conseils utiles :
Les scénarios de test écrits en Gherkin doivent se concentrer sur le comportement de l’app (d’où le Behavior Driven Development).
Voici un exemple de comment NE PAS écrire des scénarios de test en Gherkin, en explorant davantage le thème de l’application cookbook:

L’exemple ci-dessus illustre deux mauvaises pratiques que nous devrions éviter : Il se concentre sur l’implémentation au lieu du comportement et il utilise des valeurs codées en dur plutôt que d’écrire des étapes de test de manière à permettre la réutilisabilité en changeant les valeurs au sein d’une étape.

Par conséquent, un scénario correct concernant l’achat d’un livre de cuisine dans notre exemple d’application devrait ressembler à :

Un autre exemple :

Adopter cette approche signifie moins de travail pour créer et coder les étapes de test chaque fois que l’implémentation d’une fonctionnalité particulière change.

A part la notation principale de Given/When/Then, Cucumber supporte l’utilisation d’étapes de conjonction. L’utilisation des notations d’étapes And et But rendra les étapes de test plus générales et réutilisables, ce qui permet d’écrire moins de code et de maintenir l’ordre au sein du projet. Voici un exemple de base:

Donc, si vous codez l’étape ‘Given’ ci-dessus pour localiser notre élément de recette en recherchant son nom, vous pouvez la réutiliser de nombreuses fois en changeant simplement la valeur de la chaîne dans l’étape (à condition de coder correctement la définition de l’étape par la suite). En plus de cela, l’étape ‘And’ peut faire partie de tout scénario de test qui implique une telle action.

Putting it all together

Après avoir mis en place un projet utilisant les pratiques décrites ci-dessus, les parties les plus visibles de l’utilisation de Serenity sont les rapports de test générés. Après avoir adopté la balise @RunWith(CucumberWithSerenity.class) dans votre fichier de classe TestRunner, l’exécution de la suite de tests entraînera la génération par Serenity d’un rapport de résultats de tests agrégés, qui peut être utile pour évaluer la qualité de l’app testée et présenter l’état du produit aux parties prenantes ou à l’équipe de développement.

Appium, Cucumber, Serenity – Résumé

Comme vous pouvez le constater, le concept des meilleures pratiques en matière de tests d’automatisation peut être résumé en trois mots : réutilisabilité, lisibilité et performance. La réutilisabilité signifie moins de codage, diminuant par conséquent le temps nécessaire pour terminer le travail. La lisibilité améliore la compréhension, ce qui est crucial pour garantir que le produit fait ce qu’il doit faire. Enfin, la performance permet de gagner du temps d’exécution et d’améliorer la stabilité. Ces trois facteurs contribuent non seulement à la qualité du projet d’automatisation des tests, mais jouent également un rôle important dans l’amélioration de la qualité globale de l’application livrée.