Le Unit Testing je vous en ai déjà parlé, mais à propos du code, aujourd’hui il s’agit de comprendre que tester les UI est tout aussi important et de vous expliquer comment y arriver avec UITest
la complémentarité de Dot.Blog et Dot.Vlog en pratique…
Voici un sujet qui comme l’IoT est un parfait exemple de la complémentarité entre Dot.Blog que vous lisez en ce moment et Dot.Vlog la playlist de ma chaîne Youtube destinée à faire écho à mes articles par l’image.
En effet toute la présentation que vous allez lire ci-après aurait été d’un ennuyeux mortel si j’avais tourné 30 minutes de facecam avant de passer à la démonstration. De même Le pauvre Dot.Blog se trouve bien démuni lorsqu’il s’agit de présenter du visuel ou de l’action en mouvement. Quelques captures écrans, éventuellement animées en GIF, et c’est bien tout.
Ni Dot.Blog ni Dot.Vlog ne peuvent traiter à eux seul un tel sujet, mais ensemble ils y réussissent à merveille !
Je ne dis pas tout cela juste pour placer discrètement une pub pour ces deux médias qu’E-naxos produit, non. Je le dis ici et dans cet article précis car c’est le premier où cette complémentarité devient vraiment vitale.
Entendez par là que voir la vidéo Youtube sans avoir lu cet article avant la rendra totalement incompréhensible. Et lire cet article sans visionner la vidéo qui va avec laissera dans votre mémoire un souvenir abstrait sans impact réel.
Donc vous voici prévenu : lisez ce qui suit avant de voir la démo, mais vous faites ce que vous voulez, il y en a qui ont essayé, ils ont eut des problèmes, c’est vous qui voyez !
Un dernier point : j’ai lu des tonnes de choses, j’ai analysé des tas d’articles, j’ai fait beaucoup de tests. Ici je cite des produits, des phrases parfois issues d’articles, je ne pouvais pas encombrer plus le texte par de longues URL, il y en déjà assez. Vous trouverez donc en fin d’article une section Références où une grande partie des liens sont regroupés, pas tous, loin s’en faut, mais ceux qui pourront vous intéresser. Après, GETA… mais avec cet article, sa démo plus toutes les références, je pense qu’il y a déjà de quoi s'occuper un moment sans se plaindre que ça manque de références !
Qu'est-ce que UITEST ?
UITest comme son nom l'indique est un framework de Test de l'UI.
Cela consiste à automatiser les tests d'une interface visuelle de façon totalement indépendante de son code.
Les tests unitaires de code servent à valider que ce dernier est conforme aux spécifications techniques du cahiers des charges et autres documents UML produits par la phase d'analyse. Ils permettent aussi de contrôler que cette conformité résiste au temps, c’est-à-dire aux maintenances correctives et évolutives pouvant créer des régressions.
De la manière assez proche les test unitaires de l'UI servent aussi à valider la conformité d'une application mais cette fois-ci dans son aspect fonctionnel du point de vue de l'utilisateur.
Ici la base des tests est plutôt de suivre les procédures du manuel d'utilisation et de vérifier si les résultats, les enchaînements, les zones à saisir, etc, sont conformes aux descriptions et aux attentes (affichages, contenu des zones…).
Il existe de nombreux système de test d'UI. Et avant de parler de UITest de Xamarin regardons quelques-uns des plus connus.
Les autres toolbox de test d'UI
Selenium
Le produit le plus connu en gratuit mais il est destiné au Web principalement et ne nous intéresse pas ici directement. C'est un produit (et ses dérivés) très complexe et très lourd.
Les reviews semblent assez unanimes et l'extrait de l'une d'entre elles ci-dessous résument ce qui s'en dit :
"To use Selenium effectively, users have to possess advanced programming skills and need to spend considerable time to build automation frameworks and libraries necessary for automation. This is a main disadvantage of Selenium, which is addressed in integrated tools like Katalon Studio."
(“Pour utiliser efficacement Selenium, les utilisateurs doivent posséder des compétences avancées en programmation et consacrer un temps considérable à la création des infrastructures et des bibliothèques d'automatisation nécessaires à l'automatisation des tests. C'est un inconvénient majeur de Selenium, qui est réglé dans des outils intégrés tels que Katalon Studio.”)
Toutefois il en existe des versions adaptées à Android par exemple :
SelenDroid
S’il est dérivée de Selenium il n’est pas totalement identique non plus. Aucune intégration particulière avec les Xamarin.Forms et Visual Studio. Mêmes difficultés à la base que Selenium.
Selenium Appium
Là encore on se retrouve avec une usine à gaz, certainement très efficace mais à condition d'installer un serveur en Node.js d'accepter les contraintes des configurations plus ou moins mystiques du serveur et du client, etc. Et encore je ne parle pas des "drivers" qu'il faut installer et il en existe de nombreux... dont Selendroid d'ailleurs.
On empile les couches sur des couches qui installent des drivers qui discutent avec des serveurs via des clients...
C'est un cauchemar de plombier du genre tuyauterie folle à la Tuttle dans Brazil...
Kaliostest
Considéré comme plus performant et basé aussi sur Selenium Appium. Il Pose des problèmes similaires et imposent aussi des limitations de par sa volonté de simplifier Selenium.
D'ailleurs sur Appium et ses dérivés ou ascendants on peut lire ici ou là des choses de ce genre :
"Malgré tout, Appium requiert des compétences de développement précises que seuls les spécialistes de Selenium peuvent mettre en œuvre. C’est la raison d’être de certains outils comme la plate-forme kaliosTest, qui embarque cet automate de tests mobiles et permet une automatisation simplifiée, accessible à des profils de non-développeurs." (Voir la section références pour la source).
Autant dire qu'on parle ici de couches qui sont au-dessus d’autres couches elles-mêmes décorées par une couche utilisable par des soi-disant non développeurs (public visé : des testeurs non développeurs, informaticiens ratés ?). On est au summum de l'usine à gaz. Et encore une usine destinée à des équipes de testeurs dédiés uniquement à ce job, bien rodés, et le faisant tous les jours avec une formation sérieuse et chère sur le produit. Je ne conseille vraiment pas (sauf dans le cas où on doit gérer une telle équipe, l’investissement de départ peut se voir rentabilisé sur la durée, mais ce n’est pas le cadre dans lequel sont la plupart des développeurs Xamarin.Forms ni mêmes les sociétés qui l’utilisent en interne pour leurs besoins propres).
Katalon
C'est un ensemble gratuit pour le Web et les mobiles. C'est un produit à part, assez complet mais pour lequel il faut aussi une solide formation. Rien dans ce produit ne se rapproche de Xamarin ou de Visual Studio ni de C# etc. Le système utilise sa propre logique, son propre "studio" (IDE), son propre langage.
Ici aussi cela peut être un choix tout à fait intéressant pour une équipe de testeurs dans une grosse entreprise pouvant se permettre de mobiliser plusieurs personnes à l'année pour cette tâche. Dès lors peu importe la courbe d'apprentissage, un outil qu'on manipule tous les jours devient vite familier.
Mais ce n'est pas le cas de nombreux développeurs Visual Studio à qui on demande en plus de faire des tests… Ce n'est pas leur occupation principale, ils ne vont tester qu'une fois un gros projet en séparant leur temps avec de la maintenance ou de la conception… Un outil trop éloigné de Visual Studio sera pénible, et ce en permanence car l'accoutumance ne sera pas possible.
Les Autres
UFT traite lui aussi le Web, le desktop et les mobiles. Mais les prix démarrent à $3200 par an et par siège… assez dissuasif.
TestComplete est dans la même lignée à $2999 par user et par an…
SoapUI est moins puissant et ne coûte que $659 par user et par an.
Il y a aussi IBM Rational Functional Tester, comme d'habitude chez IBM, c'est du lourd et surtout impossible d'avoir un prix sans prendre un rendez-vous avec un vendeur qui va essayer de vous en mettre le maximum… Surtout que son support d'Android et iOS n'est pas certain. C'est flou. C'est IBM.
Etc, etc.
Le choix de UITEST
Je vous avoue que j'avais autre chose à faire qu'à balayer tous les machins de ce genre du marché pour en arriver toujours à la même conclusion : ce sont des usines à gaz totalement disjointes du monde Microsoft et des préoccupations des développeurs C# et XAML. Ce n’est tout simplement pas adapté à notre contexte et celui de la majorité de mes clients. Cela ne veut pas dire que ce sont de mauvais produits, ils ne sont tout simplement pas adaptés à la situation qui m’intéresse ici, c’est à dire la mienne, la vôtre, celle de mes clients, de vos clients. Toute généralité s’accompagne de son lot d’imprécisions et par force il existera parmi vous ou parmi mes clients des gens ayant des équipes de testeurs à l’année utilisant des outils complexes auxquels ils sont très bien formés, j’en ai connu, mais c’est très rare malgré tout.
J'ai donc testé UITest de Xamarin.
Il est basé sur Calabash open source maintenu par Xamarin.
Le moteur de test sous-jacent est tout bêtement Nunit, un bon framework dont les tests s'écrivent en C# et se maintiennent et exécutent sous Visual Studio. Un énorme avantage. (j’ai horreur du souligné mais là ça le méritait !).
Calabash est très ouvert et se trouve utilisé par d'autres solutions comme Calabash-concumber utilisé pour Ruby par exemple dans Android Studio notamment
Xamarin UITest est donc adapté de Calabash.iOS pour android sous C#/.NET avec une base Nunit.
UITEST est mieux adapté en utilisant et étant compatible avec les outils Microsoft et surtout avec les compétences et les connaissances des développeurs Xamarin.Forms.
UITEST Utilise Nunit, un standard utilisable sous VS Pro aussi, pas besoin d’une version Entreprise, il m’a même semblé voir des captures d’utilisation utilisant la version Community mais c’est à confirmer, ma version Entreprise de MVP ne me permet pas de le savoir…Mais si vous savez n’hésitez à le dire en commentaire je suis certain que cela intéressera de nombreux lecteurs d’obtenir une confirmation sur ce point.
UITest ouvre aussi la porte aux tests dans le cloud sur des centaines de machines différentes même si cela n'est pas une obligation et que la solution est utilisable en local, ce que nous allons faire ici.
La stratégie POP qui a été adaptée à UITest rend les tests encore plus fiables.
UITest fonctionne aussi avec Visual Studio pour Mac ce qui est un plus indéniable si on doit tester des solutions Android et iOS en même temps, car seul un Mac avec Xcode peut faire tourner l'émulateur iOS en plus de celui de Google… Toutefois cela n'est pas une grosse gêne pour les PCistes car un bon test, de code comme d'UI, s'il peut se préparer avec un émulateur n'a de véritable portée que s'il est exécuté sur les devices réellement utilisées par le client dont les noms, modèles, etc, sont spécifiés dans le contrat. Et pour cela un PC et un câble USB suffisent !
Le logiciel testé ne l'est d'ailleurs uniquement qu’en version Release et il n'y a pas besoin de le modifier (pas d'instrumentation du code). C'est une garantie absolue de tester ce qui sera livré et non de bricoler sur du code de Debug ou sur un soft qui est mis à jour en parallèle changeant sournoisement le code testé. On teste une release en particulier. Cela correspond aux normes strictes d'un testing d'UI ayant une valeur d'opposition ou de preuve.
Ce sont toutes ces raisons et d’autres qui me font vous conseiller UITest.
Toutefois comme souvent avec les produits MS qui évoluent beaucoup la doc est difficile à trouver, celle qu'on trouve est fausse car pas encore mise à jour et ne prend pas en compte les dernières évolutions, etc. Idem pour les blogs ou les vidéos qui restent assez discrets sur le sujet car les tests d'UI a fortiori sous Xamarin.Forms restent une problématique qui n'intéresse pas les masses et qui ne concerne que les gros dossiers, plus rares par essence.
Pour cet article et sa vidéo il y a donc eu un travail important de collecte de toutes les infos, de tests à construire pour échouer, chercher ce qui ne va pas, trouver de nouveaux exemples ou explications, lire et étudier les sources disponibles, recommencer, etc, jusqu'à trouver une combinaison fonctionnelle.
Mais rassurez-vous !
C'est ce travail que j'ai fait et dont je vous livre ici le résultat. Plusieurs semaines de prise de tête, mais résumées rapidement…
La Stratégie POP
Le POP (Page Object Pattern) a été choisi par les équipes Xamarin.Forms pour tester leurs applications en complément de UITest. POP se distingue du pattern Screenplay par différents aspects mais tirant leurs idées de la même source : un modèle "user-centered" proposé par Antony Marcano en 2007 dans son livre "Page Objects Refactored: SOLID Steps to the Screenplay Pattern" (écrit avec Andy Palmer, John Ferguson Smart and Jan Molak). Si vous voulez vous procurer le livre cela peut aider.
Mais Screenplay n'étant pas le sujet, je vous laisse vous plonger dans la littérature anglo-saxone très spécialisée traitant de cette variante (voir la section Références).
Donc parlons de POP Mais avant en toute logique il faudrait parler de UITest car POP n'est qu'un ajout à UITest pour le rendre plus robuste. Toutefois pour conserver une durée acceptable à cet exposé on peut juste en dire deux mots tout de suite : Page Object Patten se veut être un Pattern dans lequel on manipule des Pages plutôt que d'accéder directement aux éléments visuels. C'est une forme de "proxy" entre l'UI native et le programme de test. Le terme est trompeur, ces Pages ne sont pas des visuels, mais des objets faisant écho aux vraies pages de l’application testée. Ils sont écrits (En C#) et placés dans le code de l’application testeur. Le projet de test va ainsi contenir comme en miroir autant de "Pages" qu'il en existe dans les pages réelles de l'app. Les développeurs sont supposés développer ces pages en même temps que les pages réelles (ça c'est un idéal). Ces pages spéciales contiennent tout ce qu'il faut pour s'assurer qu'on est sur la bonne page (identification du Trait) et tout le code d'interaction. Par exemple s'il y a un bouton pour naviguer vers la page About, on trouvera d'une part la déclaration d'un objet spécial qui identifie le button en question par une query Linq sur la structure de la page réelle ainsi qu'une méthode "NavigateToAboutPage()" qui utilisera le bouton pour d'une part s'assurer de sa visibilité et d'autre part pour agir dessus (ici un Tap). Seule cette méthode sera exposée et non le bouton lui-même. Les Pages du testeur encapsule la réalité technique de l'UI pour permettre aux tests d'être purement descriptifs, faciles à lire et à comprendre.
La bonne pratique consiste à faire en sorte que chaque méthode de la page miroir du testeur retourne sa propre instance permettant ainsi une écriture de type fluent.
Ainsi les tests "réels", ceux marqués par l'attribut "[TEST]" de NUnit se lisent presque en langage naturel en appelant par exemple new PageMachin().Truc().NavigateToAboutPage();
L’un des points forts de la stratégie POP est d’évacuer les détails des objets visuels du script du test. On peut ainsi écrire beaucoup plus facilement des scénarios complexes
Concernant POP plus en détail je vais éviter les redites ici et je vous renvoie notamment à l'article en anglais suivant qui décrit ce pattern : http://www.waysoftesting.com/2017/02/14/page-objects/
Vous trouverez d'autres sources du même type sur Google, en anglais bien entendu, ce n'est qu'un exemple.
UITest
Implémentation
Les Grandes lignes sans utiliser de template (des explications plus détaillées suivent)
De façon alternative vous pouvez ajouter manuellement les fichiers suivants (en prenant soin de changer les namespaces en accord avec ceux de votre projet) :
Pour plus d'information lire le wiki. (https://github.com/xamarin-automation-service/uitest-pop-example/wiki/POP-Implementation)
On peut aussi consulter l'exemple suivant : https://github.com/xamarin-automation-service/uitest-pop-example
Le bon cadre de travail
Je vous avouerai que cela n'a pas marché du premier coup… Il m'a fallu au moins une semaine pour assimiler les docs éparses et partiellement fausses et presque autant pour comprendre toutes les étapes nécessaires pour obtenir un environnement qui fonctionne. Car ici nous avons un problème de configuration et de versions des outils. Le principe est très simple et on croit s'en sortir en une heure. C'est vrai pour la compréhension du mécanisme, c'est faux pour la recherche des combinaisons de paquets, de VSIX, etc.
Il est vrai que c'est une étape qu'on ne fait qu'une fois par projet, généralement sur de gros projets ayant le budget pour l'UI Testing, sinon ce n'est pas la peine. Car cela va consommer beaucoup de temps sachez-le. Toutefois la partie la plus longue et la plus délicate est la compréhension et la mise en place d'un ensemble de versions de VSIX et paquets qui fonctionnent. Ca je l'ai fait pour vous vous ne devriez pas perdre ce temps-là, et c'est énorme !
Les tests d'UI sont longs à mettre en place. Mais lorsqu'ils marchent ils assurent une qualité professionnelle au produit.
Si le client le comprend il payera pour cette qualité, s'il ne comprend pas ce n'est pas un effort que vous pourrez financer sur votre marge cela l'absorbera et peut-être plus.
Les Test unitaires du code sont déjà coûteux, ceux de l'UI le sont tout autant si ce n'est plus et viennent s'ajouter à l'addition. Le prix d'un logiciel bien conçu ne doit pas se baser sur celui de la production du seul code en journée de dev.
Il y a l'encadrement, les réunions, la planification, le reverse engineering sur du code legacy non ou mal documenté, l'extraction ou l'écriture des règles métiers, etc, puis seulement vient le code, puis ensuite les test unitaires (pour le code c'est en simultané dans l'idéal). On peut estimer qu'un logiciel bien fait et bien testé coûte environ 2 à 3 fois le prix de l'estimation du codage seul… Et je ne compte pas une analyse bien faite en UML, ni l'écriture d'une doc technique à jour méritant ce nom et encore moins l'écriture de la documentation utilisateur et la conception des systèmes d'aide séparés ou embarqués dans l'application… J'ose à peine évoquer et ajouter à cette liste l'intervention d'un vrai designer pour concevoir les pages...
Bref faire du Unit Testing pour le code c'est cher, si on ajoute l'UI c'est très cher…
Voici de façon plus pratique les choses que j'ai découvertes qui chacune n'ont parfois pas été suffisantes mais qui ensemble font que cela fonctionne :
On notera avant tout que cela ne concerne pas le projet testé qui sera sous la forme d'un APK (ou équivalent pour iOS). Le projet testeur est celui qui est le plus sensible donc.
Définir la variable d'environnement ANDROID_HOME pour la faire pointer le SDK. Ne suffit pas et n'est peut-être pas indispensable. C'est un conseil qu'on peut lire ici et là, alors autant le faire même si je doute.
Très important, au moment où j'écris (septembre 2019) Il faut utiliser Xamarin.UITest en version 2.2.6 et Nunit en 2.6.4. Toute utilisation d'autres versions devra se tester sur une configuration qui fonctionne déjà, et pas par pas pour valider le nouveau couple de nugets. Mais cela ne suffit pas à ce stade.
On peut lire parfois qu'il faut downgrader le SDK Tools Android en 25.2.5 mais cela bloque plus tard d'autres choses. Je suis donc resté avec le dernier dispo à la date soit le 26.1.1
Plutôt que d'utiliser le nuget NunitTestAdapter j'ai découvert qu'il fallait plutôt installer le VSIX Nunit Test Adapter 2
https://marketplace.visualstudio.com/items?itemName=NUnitDevelopers.NUnitTestAdapter
Supprimer le package nuget équivalent si jamais il a été installé (avant l'install du VSIX c'est mieux)
La base : Nunit et UITEST ne savent pas lancer l'émulateur (conçu au départ pour tourner sur une device existante réelle) il faut donc lancer l'émulateur Android avant de lancer des tests. C'est l'une des clés de la réussite.
L'appli peut être faite en n'importe quoi, Xamarin.Droid, Xamarin.Forms ou n'importe quoi d'autre, c'est un APK natif qui est testé. Tant qu'on dispose d'un environnement générant des APK on peut le tester ainsi. C'est d'ailleurs l'essence de Calabash dont UITEST est une adaptation pour VS/Xamarin.Forms.
Ne pas oublier donc en mode Release de demander au projet Android de générer toutes les cibles possibles (Dans VS2017 et 2019 l'image peut être différente, ici c'est VS Mac)
Dans le mode release global (gestion des configurations) je conseille de laisser le projet de test en mode Debug, c'est mieux pour avancer dans l'écriture des tests et pouvoir les déboguer. C'est une appli comme les autres.. Et elle est en cours d'écriture, pas comme le APK qu'on teste…
ScreenShots
Le système de test autorise la prise de Snapshot ce qui est très utile (encore plus en mode déporté sur des centaines de machines mais qui marche aussi en mode local). Le nom qu'on donne (en paramètre de la méthode) n'est pas utilisé lorsqu'on utilise le mode local. Les images portent des noms séquentiels SnapShot-1 -2 etc. Elles sont stockées dans le projet de test dans /bin/debug
Mais pour que cela fonctionne en local il faut le déclarer en ajoutant .EnableLocalScreenShots() dans l'initialiseur de l'app de test (voir code source de mon exemple).
L'APK testé
On teste l'APK d'une App bien définie dans une version bien précise. Pour cela il faut un APK créé en mode Release.
Le mode Release ne génère pas d'APK comme le mode debug… il faut générer le projet à tester en Release puis faire un click droit sur son nom dans l'explorateur de solution et demander la génération d'une Archive. Ouvrir le dossier des archives, supprimer éventuellement celles qui ne servent plus ou les déplacer en sécurité ailleurs pour en pas se mélanger. Dans le dossier repérer le APK qui a le nom le plus simple, celui de votre App, sans ajout de -Signed par exemple à la fin.
Copier le chemin d'accès complet vers cet APK c'est ce nom complet que vous utilisez dans le project manager d'UITEST, au moins pour l'APK Android.
iOS est une autre affaire que je n'ai pas testée totalement ici donc je n'en parle pas, sachant qu'il n'y a pas d'émulateur pour iOS. Donc pour faire des tests sur un projet iOS ou mixte (iOS/Android) je conseille vivement d'utiliser VS Mac sur un Mac donc.. Car lui contient Xcode et son émulateur et il peut aussi faire tourner l'émulateur Android. Sous Windows on peut juste avoir l'émulateur Android mais jamais celui de Apple qu'ils ne partagent pas…
Mise en œuvre
Pas besoin du code source de l'app donc, juste un APK en mode release.
On peut tester sur device réelle mais aussi sur émulateur, il faut qu'il soit lancé avant, le système de test ne sait pas invoquer les émulateurs tout seul. Ce qui permet d'ailleurs au testeur de choisir lui-même quel émulateur lancer. (pour Android, pour iOS pas d'émulateur ..rappel sauf si on choisit de travailler sur VS Mac ce que je conseille pour un projet mixte iOS/Android).
Ajouter un projet "UI Test App" C# via le Template du VSIX (voir plus haut)
Les 4 composantes indispensable comme évoqué rapidement plus haut sont :
Précise le nom et l'emplacement des apps iOS et Android.
En général on travaille sur un APK dans un dossier séparé pour ne pas être victime des changements faits durant le dev de l'app. On teste ainsi une version précise qui n'est pas changeante. C'est plus fiable. Plus précis.
La classe démarre l'app et permet de s'adapter à iOS ou Android même quand les deux existent en même temps
Helper pour tous les tests, setup pour chaque test, etc. Déclare des helpers comme OnAndroid ou OndiOS pour simplifier l'écriture. Car n'oublions pas que les tests sont cross-plateforme.
Pré-setup, lancement de pages indispensables etc. C'est là qu'on peut remplir un login par exemple afin de permettre à chaque test d'entrer dans le soft sans le répéter dans chaque test.
Base des pages, pour chaque page de l'app.
Contient le Trait qui permet d'identifier la page à coup sûr, unique élément ou conjonction si un seul pas possible.
AssertOnPage pour attendre que la page est bien là (avec timeout réglable)
WaitForPageToLeave vérifie que le Trait n'est plus présent à l'écran
On peut ajouter du code qui s'appliquent à toutes les pages.
C'est un helper pour différencier les plateformes visées.
Test.cs
Ce sont les tests, basés sur BaseTestFixture
Utilisation de [TEST] attribute.
Création du scénario, des pages, du cheminent, etc. Utilise les Pages spéciales de test pour clarifier la progression, c'est çà POP.
Pages
Alias de simplification pour utiliser le moteur.
Astuces indispensables à connaître
Chaque page de test doit repérer les éléments d'UI pour interagir avec eux.
Le plus simple pour s'assurer d'utiliser les bons objets est de faire une pause app.Repl(); dans le test en cours d'écriture dès qu'il se trouve sur la page à tester. Grâce à ses nombreuses commandes on peut : Tree, voir l'arbre visuel et trouver ce qui distingue un élément d'un autre, Flash, qui fait flasher un élément pour tester une requête de reconnaissance (des lambda utilisant des méthodes spéciales telles Marked(), Class(), etc).
On peut aussi avec cette console s'assurer qu'un élément est visible car les tests ne marchent que sur ce qui est visible. Même si la page Xamarin.Forms est unique, si elle est trop longue pour l'écran seul ce qui sera visible pourra être testé. Il est donc nécessaire d'utiliser des app.ScollDown ou mieux ScrollDownTo() utilisant l'expression trouvée par le Tree et validée par le Flash…
Mais ces expressions ne sont pas facilement exploitables dans UITest, il faut ajouter une astuce supplémentaire, dans chaque fichier page :
Un bouton ou tout élément d'UI sera ainsi déclaré comme étant de type Query et il sera initialisé dans le constructeur de la page de test en passant directement la même lambda que celle écrite et testée dans Repl() ! Et tout devient plus facile…
La Démo, la Vidéo
Voyons maintenant rapidement une démonstration d'un projet de test que j'ai écrit de A à Z c’est-à-dire en partant d'une App vierge Xamarin.Forms et en créant une App à plusieurs écrans dont un login, puis en créant le projet testeur. L’application de base est proche de l’architecture de toute App d’entreprise avec son Login et ses multiples pages. Elle représente bien ce qu’on a a tester généralement même si ici rien n’est vraiment fonctionnel. Mais ce n’est pas le code que nous allons tester, mais l’UI…
Les tests ne vont pas très loin car ce que je souhaite ici c'est vous mettre le pied à l'étrier, écrire tous les tests pour ce projet de démo aurait été une pure perte de temps ne vous en apprenant pas plus. Au-delà il faudra une éventuelle assistance ou formation, et c'est mon métier justement, le hasard fait bien les choses ! :-)
Il est temps de visionner la démo : https://youtu.be/YzVF-Y-Kt7k (disponible à 9h15 le jour de la parution du papier)
Le code source de l'exemple traité dans la vidéo se trouve ici :
https://www.dropbox.com/s/u5fup7278h9x2uw/DotVlog23UITest.zip?dl=0
Références
Comme annoncé dans l’introduction de ce papier voici les liens vers les documentations diverses et variées, les articles ou autres qui, en partie seulement, m’ont permis de progresser sur cette sinueuse route de l’UI Testing. Je vous en souhaite bonne lecture ! (La majorité des liens contiennent le titre de ce qu’ils pointent et sont ainsi auto-explicatifs, pour les autres, ouvrez-les, c’est une sorte de surprise !).
Conclusion
Le Unit Testing de code n’est pas une mince affaire, mais tout se joue entre du code et du code au final. Pour peu que le logiciel a tester soi écrit selon les règles de l’art et qu’il adopte correctement MVVM notamment, c’est une piece of cake…
En revanche tester les UI c’est plus chaud. L’UI c’est complexe, c’est impalpable, des dessins, des couleurs, du texte, des mises en page fluctuantes et dynamiques, etc. Mais pire pour nous, il s’agit ici de tester des UI d’applications transformées par des compilateurs en natif pour d’autres OS, le tout fonctionnant en général sur des devices mobiles de marque, de form factor, de résolutions différents.
Les outils pour y arriver sont autrement plus complexes et techniques.
Malgré tout en choisissant un framework qui reste dans le giron de Visual Studio et de Xamarin on s’évite les terribles pertes de temps à apprendre d’autres langages, d’autres IDE, d’autres mondes dont on ne profitera vraiment jamais car ce n’est pas notre activité principale et que la prochaine fois qu’on s’en servira on aura tout oublié ou presque…
Avec UITest on réutilise son savoir faire de NUnit par exemple, on code ses tests en C# aussi, on exécute et on débogue ses tests depuis Visual Studio.
UITest n’est peut-être pas le meilleur framework, mais c’est celui qui est le mieux adapté et qui vous fera perdre le moins de temps.
Surtout si vous suivez mes conseils… Alors …
Stay Tuned !