Amélioration des performances des tests automatiques et simplification du code en nettoyant les filtres de recherches

Description de la problématique

Lorsque l'on réalise des tests automatisés, on doit systématiquement se poser la question de la maintenance de ces tests pour essayer de coder les tests de la manière la plus simple afin de pouvoir corriger d'éventuel futur modification de l'application

J'ai lu dans certaines bonnes pratiques qu'il fallait enregistrer toutes les actions sur tous les écrans, cette solution ne me convient pas car elle complique les fichiers UI Test Map de manière conséquente et complique donc la maintenance alors que l'on peut contourner ce problème de manière assez simple.

L'objectif est de simplifier au maximum le fichier uitest sans ralentir les exécutions des tests, en ayant une seule action qui sera appeler pour chaque écran.

Exemple de ce que l'on a à tester:

Nous avons un même bouton retour qui est situé sur 2 écrans différents (pour cet exemple mais utiliser de nombreuses fois dans l'application), nous souhaitons donc enregistrer une seule fois l'action "Retour" et l'appeler dès que nous en aurons besoin dans chaque test.

Voici les tests que nous allons effectuer pour expliquer cet exemple:

Test1:

lancement de l'application, connexion avec un compte utilisateur, clique sur le bouton Gestionnaires de zone, clique sur le bouton retour, vérification du texte de la homepage

Test2:

lancement de l'application, connexion avec un compte utilisateur, clique sur le bouton Gestionnaires locaux, clique sur le bouton retour, vérification du texte de la homepage

Problème: Enregistrement de toutes les actions sur tous les écrans

Voici l'UIMap suite à l'enregistrement de la même action sur les 2 écrans:

En exécutant les 2 tests suite à cet enregistrement, on constate des performances satisfaisante (Test1 : 15 secondes, test2: 14 secondes).

Par contre on imagine bien que le code sera difficilement maintenable lorsque nous aurons enregistré toutes les actions de notre application.

Si le bouton "Retour" est présent 10 fois dans l'application et qu'il vient à être modifier, il faudra refaire l'enregistrement 10 fois.

Contournement du problème

Nous allons donc contourner ce problème en enregistrant un seul bouton retour que nous allons appeler dans tous nos tests.

Je commence par enregistrer une seul fois l'action de clic  sur le bouton "Retour"

Voici l'UIMap suite à l'enregistrement de mon action:

Dans un premier temps nous allons appeler cette fonction dans nos tests et voir les performances de ceux-ci

Suite à une exécution de ces 2 tests sans effectuer aucune modification dans les filtres de recherche, voici les performances obtenues:

Test 1: OK, temps: 13 secondes

Test2: OK, temps: 34 secondes

Problème: On constate une perte de temps énorme entre les 2 tests malgré la simplicité de ceux-ci, on peut donc comprendre rapidement le problème lorsque l'on aura des test avec plus de 10 actions.

Amélioration des performances

La solution à ce problème consiste à modifier les filtres de recherche des éléments dans le fichier uitest.

Les propriétés de recherches susceptibles d'être modifiés sont:

Filter Properties, Search Properties et Windows Titles

NB: il faut modifier les propriétés pour le bouton lui-même mais également pour ces parents.

Dans mon exemple voici les actions que je vais effectuer pour améliorer la performance:

• Supprimer tous les window tilles de chaque niveaux de hiérarchie

• Supprimer le "name" dans les search properties du niveau le plus haut

• Supprimer certaines filter properties afin de garder uniquement celles qui me sont utiles (Uniquement Id si présent, sinon Innertext…)

Suite à ces modifications, on constate que l'exécution des tests est maintenant bien plus rapide, nous avons retrouvé les mêmes performances que lorsque l'on enregistre toutes les actions .

Test1: 14 secondes

Test2: 12 secondes

Maintenant que nous avons retrouver de bonnes performances en utilisant une seule action, nous allons créer une branche qui contiendra toutes nos actions qui sont transverses à l'application.

Ui Map avant modification:

Dans mon exemple, j'ai uniquement un uiobject dans ma branche UIAdminAnnuaireAdminisWindow, je vais donc renommer cette branche pour qu'elle contienne tous mes éléments transverses à l'application en gardant la même norme de nommage "UI...nom...Window", et je sauvegarde le fichier uitest pour régénérer le fichier designer.cs. Cette branche servira ensuite à stocker toutes nos actions transverses.

Afin de faciliter la maintenance futur de ce fichier uitest (car nous devrons déplacer les actions transverses dans cette branche), nous allons maintenant déplacer la branche que l'on vient de renommer (ici UIElementTransverse) en première position dans mon Treeview.

Ouvrir le fichier uitest avec un editeur xaml

Dans ce fichier on peut distinguer 3 grosses parties:

• Configuration

• ExecuteActions

• Maps

Dans le bloc "Maps" on observe 3 niveaux "TopLevelWindow" qui correspondent à mes 3 branches principales

Il suffit donc de déplacer Le TopLevelWindow UIElementTransverseWindow pour le placer en premier, on sauvegarde nos modifications et on va pouvoir constater le résultat en ouvrant le treeview.

Conclusion

Dans cet article, nous avons vu comment réduire considérablement le nombre d'actions enregistrées en modifiant les filtres des actions qui sont réutilisées plusieurs fois dans l'application, ainsi sans perdre de performance lors de l'exécution, on simplifie:

L'appel à ces actions (développement des tests simplifié)

L'architecture du fichier xaml (maintenance et compréhension)

Nous verrons dans un prochain post comment organiser les branches du fichier uitest afin d'éviter les doublons et de s'y retrouver facilement.