La préparation de tests avec Appium se fait souvent avec Appium Inspector. Sur Windows, il y a de meilleures alternatives : Accessibility Insights, et Inspect. Ces alternatives peuvent être utilisées sans que l’application cible soit pilotée par Appium (ce qui est bien plus pratique). Celles-ci permettent donc une inspection des Controls plus simple, et plus rapide.

Personnellement, j’ai un petit faible pour Accessibility Insights. L’application est moderne et offre un rendu très clair des Controls observés. Accessiblility Insights pour Windows peut être téléchargé ici.

Inspect de son côté a une interface un peu datée. Il n’en est pas pour autant moins efficace. Inspect fait partie du SDK Windows. On peut le trouver dans le répertoire " C:\Program Files (x86)\Windows Kits\10\bin\10.0.22000.0\x86" (à adapter en fonction du SDK installé).

Attention à ne pas faire l’impasse sur Inspect. Accessibility Insight sera très efficace sur des applications modernes à base de XAML, d’Electron ou WInForm bien structurée. Cependant, il manquera des informations sur certaines vieilles applications. Je n’ai pas encore identifié de raison claire à cela. J’ai juste constaté des problèmes avec des applications Winforms .net 4 à 4.6 utilisant des Controls fournis par un éditeur tiers.

Depuis les premiers jours de ce blog, j’ai pris l’habitude de partager son code sur GitHub. Dans les faits, il existe deux versions de ce code :

• La version publique sur GitHub
• La version privée sur Azure DevOps

La seconde version me permet de gérer facilement les adaptations que j’ai réalisées pour mes propres besoins. Je m’en sers aussi pour effectuer quelques tests et démos DevOps.

Malheureusement, par manque de temps je n’ai pas poussé d’évolution sur GitHub depuis quelques mois. Je suis désolé. J’ai pris le temps de rectifier cela lundi.

Le code partagé contient :

• Le support de .net 6.
• L’amélioration de l’accessibilité.
• Le renforcement de la sécurité.

Si vous n’avez jamais utilisé un outil permettant d’automatiser des tests d’interface utilisateur, vous ne voyez certainement pas l’objet de cet article. Alors faisons clair. Si vous avez déjà utilisé Code UI de Microsoft, l’automatisation de tests d’UI peut sembler être un sujet trivial. On dispose d’un outil tout intégré qui permet l’enregistrement de tests. C’est sympathique, c’est mignon et cela fait le job…

Franchement ?

Dans la pratique, ce genre de tests peut être un véritable calvaire. Le moindre changement d’UI de l’application testée peut casser la totalité des tests.

Le problème ne vient pas de la technologie, mais de la manière de l’utiliser. La création de tests d’UI doit suivre les mêmes de qualité que tout code :

• Si l’on base la totalité de ses tests d’UI sur un outil qui enregistre ceux-ci comme s’il s’agissait de macro Excel, on a très peu de chances d’avoir la main sur le code du test, ou d'avoir un test simple et clair.
• Si l’on a accès au code des tests, mais que ceux-ci s’appuient sur le positionnement des contrôles, le moindre déplacement va avoir un impacte. Il en est de même si le style de l’Ui est modifié.
• Si une personne effectue un refactoring de l’UI en renommant des Controls, les tests seront en échec.

Comment s’en sortir ?

Il est un élément qui n’est pas perturbé quand seul le design évolue. Il s’agit des propriétés chargées de fournir des informations au lecteur d’écran (text, descriptions, rôles …).

Oui, je suis en train de dire qu’une application accessible est plus facilement testable qu’une application qui ne l’est pas ;)

Si vous utilisez un framework de tests d’UI, ou que vous avez l’intention d’en utiliser un, basez toujours vos tests sur les solutions d’accessibilité offertes par votre plateforme. Toutes offrent des sélecteurs permettant de trouver un Control d’après les informations d’accessibilité qu’il expose. Si ce n’est pas le cas, changez d’outils. Cela vous évitera de perdre beaucoup de temps.

Changement d’heure oblige, j’ai pris le temps de partager le code de l’une de mes montres accessibles. Cela se passe ici.

Comme à l’habitude, je suis ouvert à toute proposition (pour l’amélioration d’une montre, ou la création d’une nouvelle).

Comme évoqué dans mon précédent article, pnpm peut être un véritable atout pour vos builds. Sa mise en place n’est pas très compliquée. Elle implique la mise en place d’une tâche d’installation de pnpm suivi d’une tâche d’installation des modules utiles à nos applications.

Dans le cadre d’un pipeline YAML, le code à utiliser est le suivant :

# Node tasks
- task: [email protected]
  displayName: 'Installer pnpm'
  inputs:
    script: npm install -g pnpm
- task: [email protected]
  displayName: 'Installer les modules via pnpm'
  inputs:
    script: pnpm install
    workingDirectory: $(Build.SourcesDirectory)/sources/website

Bien évidemment, il faut adapter workingDirectory en fonction du dossier dans lequel se trouve le site ou l’application dépendant de nodejs.