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.