Et quatre façons de le trouver.
L’identifiant est pourtant unique : le développeur l’a posé une fois, dans le code partagé. Ce qui change, c’est l’attribut sous lequel chaque système d’exploitation l’expose à l’automatisation.
Android //*[@resource-id='...']
iOS //*[@name='...']
Windows //*[@AutomationId='...']
iPadOS parfois encore autre chose
Le dernier cas mérite qu’on s’y arrête. iPadOS partage l’essentiel de son comportement avec iOS, mais pas toujours : une disposition en plusieurs colonnes, un composant qui devient une barre latérale, un élément présent sur l’un et absent sur l’autre. Traiter iPad comme un iOS suffit dans la majorité des cas, et échoue dans quelques-uns. C’est exactement le genre d’exception qui empoisonne une architecture si on ne lui prévoit pas de place.
Dupliquer la suite par plateforme. Chaque scénario existe en quatre exemplaires. Une évolution fonctionnelle se répercute quatre fois, et le jour où l’une des copies prend du retard, plus personne ne sait laquelle fait foi. La maintenance est multipliée par quatre, mais surtout, la confiance est divisée.
Semer des conditions dans les tests. Le scénario métier se retrouve noyé sous
la plomberie. Un test censé décrire un parcours d’achat parle soudain de
resource-id et de AutomationId. Il devient illisible pour la seule personne
qui devrait pouvoir le relire : celle qui connaît le métier, pas l’outil.
Les deux approches ont le même défaut de fond : elles laissent une question d’infrastructure remonter jusqu’au niveau où l’on décrit le comportement attendu.
C’est tout le principe, et il tient en une phrase.
La condition est irréductible : quatre plateformes exposent quatre attributs, il faudra bien choisir à un moment. Ce qui se décide, c’est où ce choix est écrit.
Une seule couche le porte. Les tests n’en savent rien. Les éléments sont déclarés au même endroit, avec deux cas de figure :
Le second point est ce qui rend le premier tenable. Sans lui, la moindre exception ferait sauter tout l’édifice et ramènerait les conditions dans les tests.
Une montée de version du système qui casse un sélecteur iOS, c’est une ligne à corriger. Pas une chasse à travers toute la suite, pas un inventaire des endroits où cet élément est mentionné.
C’est la différence entre un correctif de deux minutes et une demi-journée de recherche, répétée à chaque mise à jour majeure. Sur un cycle de plusieurs années, c’est cette ligne-là qui décide si la suite de tests survit ou si elle est abandonnée.
Trois règles, dans cet ordre :
default commun.Le troisième point est le plus important, et c’est celui qu’on oublie en écrivant ce genre de couche. Un sélecteur introuvable qui renvoie une chaîne vide produit un échec à retardement, dans un message qui ne parle ni de plateforme ni de déclaration manquante. Mieux vaut échouer tout de suite, en nommant la cause.
Un dernier détail fait la différence à l’usage : la couche peut lire la plateforme directement depuis la session d’automatisation en cours, au lieu de la recevoir en paramètre.
use_appium(driver) # la session connaît déjà sa plateforme
LOGIN.resolve() # le bon sélecteur, sans rien déclarer
L’intérêt n’est pas d’économiser une ligne. C’est qu’une déclaration manuelle est
une information dupliquée, donc une information qui finira par mentir : on lance
sur iPad avec un paramètre resté sur ios, et le test échoue en désignant un
élément, jamais la configuration.
Ce besoin n’a rien de spécifique à mon projet. Toute équipe qui teste la même application sur plusieurs systèmes rencontre exactement le même mur.
Je l’ai donc sorti de mon dépôt :
pip install crosslocator
Zéro dépendance d’exécution, typé, sous licence MIT. Il fournit des mots-clés Robot Framework, et des exemples exécutables sans appareil connecté, pour qu’on puisse le juger avant de l’installer quelque part.
L’adoption se fait écran par écran : rien n’oblige à convertir une suite entière. Un seul écran migré suffit à voir ce que ça donne.
Un mot là-dessus, parce que c’est ce qui manque à la plupart des annonces d’outils.
Il n’encapsule pas le driver. Il ne fait que router des chaînes de sélecteurs, et vous les passez à votre bibliothèque habituelle comme avant. C’est délibéré : une couche qui s’interpose entre le test et le driver devient une dépendance dont on ne sort plus, et elle casse à chaque montée de version de ce qu’elle enveloppe.
Il ne corrige pas non plus un mauvais ancrage. Si votre identifiant est régénéré à chaque compilation, il sera tout aussi instable une fois déclaré proprement. Ranger le problème ne le résout pas : c’est une autre discussion, et elle vient avant celle-ci.
Le code, la documentation et les exemples : github.com/julien-becheny/crosslocator
]]>Alors quand une suite atteint quelques centaines de tests, un objectif s’installe en permanence : réduire le temps d’exécution. On commence par les suspects habituels. Paralléliser. Supprimer les attentes fixes. Découper par tags.
J’ai fait tout ça. Puis j’ai mesuré où partait réellement le temps, et la réponse n’était dans aucune de ces trois cases.
Sept dixièmes du temps d’exécution étaient consommés par la préparation des données, clic après clic dans l’interface. La vérification, celle pour laquelle le test existe, tenait dans les trois dixièmes restants.
Ce chiffre n’était pas une impression. C’est le point important, et c’est d’ailleurs le seul travail qui n’est pas optionnel dans toute cette histoire.
Un test qui crée un dossier, saisit une fiche, valide un formulaire puis vérifie qu’un montant s’affiche correctement passe l’essentiel de son temps dans les trois premières étapes. Aucune d’elles n’est le sujet du test. Elles sont la condition pour que le sujet existe.
Tant qu’on ne sépare pas ces deux natures dans la mesure, on optimise à l’aveugle. On gagne trois secondes sur une attente pendant que quarante secondes partent dans une saisie de formulaire qui ne fait pas l’objet du test.
Le coût évident, c’est le temps. Il y en a un second, moins visible et plus cher.
Chaque écran traversé pour préparer une donnée est une occasion de casser. Un libellé qui change, un champ qui se décale, une popup de mise à jour qui s’intercale, une lenteur réseau sur un écran intermédiaire. Le test échoue, et il échoue dans une étape qui ne l’intéressait pas.
C’est la pire catégorie d’échec. Le rapport est rouge, mais le produit va bien. Il faut ouvrir les journaux, comprendre qu’on est tombé à l’étape 4 sur 12, et constater que rien de ce que le test devait vérifier n’a été atteint. Le temps perdu à diagnostiquer dépasse souvent le temps qu’on cherchait à économiser.
Plus grave encore : à force, l’équipe apprend que le rouge ne veut rien dire.
Le pattern tient en une phrase : mise en condition par l’API, vérification par l’interface.
Le test ne clique plus pour créer son contexte. Il l’obtient par des appels directs, en quelques secondes. Puis il ouvre l’application et vérifie uniquement ce qu’il est censé vérifier.
Ce n’est pas une astuce de contournement. C’est une remise au bon niveau : un test doit passer son temps sur son sujet. Tout le reste est de l’infrastructure, et l’infrastructure n’a pas à être jouée par un humain simulé.
C’est la partie que les articles sur ce sujet oublient, et c’est elle qui décide si le pattern tient dans la durée.
Quand le parcours utilisateur est le sujet du test, on reste intégralement sur l’interface. Un test qui vérifie qu’on peut créer un dossier doit créer ce dossier en cliquant. Sinon il ne teste plus rien.
La règle que j’applique est simple à énoncer : si l’étape fait partie de ce que le test affirme, elle passe par l’interface. Si elle est seulement nécessaire pour que l’affirmation ait un sens, elle peut passer par l’API.
Conséquence directe : les deux modes doivent coexister. Il ne s’agit pas de migrer une suite de l’un vers l’autre, mais d’avoir les deux disponibles, et de choisir par test.
Trois contraintes, et elles ne sont pas négociables. Sans elles, on obtient deux suites de tests au lieu d’une, et la maintenance double au lieu de baisser.
Un seul jeu de données de test. Les valeurs sont décrites une fois, au même endroit, indépendamment du chemin par lequel elles arrivent dans l’application. Le mode d’injection est un détail d’exécution, pas une propriété de la donnée. Si vous vous retrouvez avec un fichier de données pour l’API et un autre pour l’interface, ils divergeront avant la fin du mois.
Un seul jeu d’assertions. Ce qui est vérifié ne change pas selon le mode. Un test qui n’affirme pas la même chose dans les deux modes n’est plus le même test, et vous ne pouvez plus comparer leurs résultats.
Un interrupteur, pas une réécriture. Le basculement se fait par un paramètre au lancement. Le même fichier de test tourne dans les deux modes. C’est ce qui permet de vérifier, quand un doute apparaît, que l’écart de comportement vient bien du produit et non du raccourci.
L’API et l’interface ne produisent pas exactement le même état. Un champ calculé côté client, une valeur par défaut appliquée par le formulaire et pas par le service, et voilà deux contextes qui se ressemblent sans être identiques. Le test s’exécute alors sur un état qui n’existerait jamais en production, ou il échoue pour une raison sans rapport avec ce qu’il vérifie. Le seul remède est de comparer les deux états réellement obtenus, au lieu de supposer qu’ils coïncident.
Le mappage des données de test existantes vers ce qu’attend le point d’entrée. Les jeux de données sont écrits dans le vocabulaire du métier ; l’API attend sa propre structure, ses propres noms de champs, ses propres formats. Il faut donc une traduction entre les deux, et cette traduction est du code à maintenir. C’est le vrai coût d’entrée du pattern, et il est régulièrement sous-estimé : le gain ne commence qu’une fois cette couche écrite.
Savoir ce que chaque point d’entrée attend vraiment. Un champ oublié, ou au contraire un champ envoyé alors qu’il aurait dû rester vide, et le test travaille sur un contexte faux. Rien ne le signale : l’appel réussit, l’application affiche quelque chose, le test rend un verdict. C’est le piège le plus coûteux parce qu’il est silencieux, et un verdict faux vaut moins qu’une erreur franche.
Sur le périmètre concerné :
Le gain de temps est celui qu’on met en avant. Ce n’est pourtant pas le plus important.
Le vrai bénéfice, c’est qu’un test en échec redevient une information. Quand un test ne traverse plus que ce qu’il vérifie, un rouge signifie quelque chose. Et un rapport qui signifie quelque chose se lit, au lieu d’être relancé.
]]>Sur le papier.
Un principe de base veut que chaque test soit maître de ses données. Il crée ce dont il a besoin, il le nettoie, il n’interfère avec personne. Le principe est bon, et je l’applique.
Mais il ne couvre pas tout. Certains réglages sont globaux par nature : les tests ne peuvent que se les partager. Ils ne les possèdent pas, ils les empruntent.
L’exemple est trivial à décrire. Un paramètre vaut 15 par défaut. Mon test a besoin qu’il vaille 10. Si la restauration ne passe pas, il reste à 10, et le test suivant, qui attend 15, tombe.
Il ne s’exécute pas quand l’application plante. Ni quand la session mobile meurt. Ni quand quelqu’un arrête le run en cours. Dans ces trois cas, le réglage reste modifié, et la suite continue de tourner dans un monde que plus personne ne décrit.
Ce n’est pas un défaut d’implémentation qu’on corrigerait en écrivant un meilleur teardown. C’est structurel : le teardown vit dans le processus qu’il est censé rattraper. Quand ce processus disparaît, il disparaît avec lui. On peut l’entourer de gestionnaires d’erreurs, de tentatives, de délais de grâce, on ne change rien au cas qui compte vraiment, celui où il n’y a plus personne pour exécuter quoi que ce soit.
Un réglage global modifié ne fait pas échouer le test suivant. Il fait échouer certains tests suivants, parfois des dizaines plus loin, parfois seulement ceux qui traversent l’écran concerné.
Le rapport affiche alors une grappe d’échecs qui n’ont rien en commun, aucun ne correspondant à une régression du produit. Le vrai coupable, lui, est passé au vert : il a fait son travail, il a même parfois détecté le bug qu’on lui demandait de détecter. Il a juste laissé la pièce en désordre avant de mourir.
Diagnostiquer cette situation demande de remonter la chronologie complète du run, d’identifier quel test a touché quoi, et de reconstituer l’état à chaque étape. C’est long, et c’est à refaire à chaque fois. Le symptôme le plus courant, dans une équipe, c’est la phrase « relance, ça passera ».
J’ai arrêté de chercher à rendre le teardown infaillible. Pas de l’utiliser : il reste en place, et c’est lui qui restaure dans la quasi-totalité des exécutions. Sous Robot Framework, il s’exécute d’ailleurs quel que soit le verdict du test, comme il doit. Ce qu’il ne sait pas faire, c’est survivre à la mort du processus.
Le changement n’est donc pas un remplacement, c’est un ajout : une vérification supplémentaire à l’entrée. Un test ne suppose plus que la place est propre, il s’en assure avant de commencer.
Avant de toucher un réglage sensible, le test inscrit ce qu’il s’apprête à faire dans un journal d’état, écrit hors du processus :
L’ordre compte. L’écriture précède la modification, jamais l’inverse. Si le programme meurt entre les deux, le pire scénario est une entrée qui décrit une modification qui n’a pas eu lieu, et la réparation sera sans effet. L’ordre inverse produirait le cas dangereux : une modification réelle dont plus rien ne garde la trace.
Le mot important est hors du processus. Une variable, une liste en mémoire, un attribut de classe : tout cela meurt avec le programme, exactement au moment où l’information devient nécessaire. Un fichier survit au plantage, à l’arrêt manuel, et même au redémarrage de la machine.
Le teardown, quand il s’exécute, restaure la valeur et marque l’entrée soldée. C’est le cas nominal, et il couvre la grande majorité des exécutions.
Le reste tient dans une seule règle : chaque setup relit le journal et répare ce qui traîne. Si une entrée non soldée est là, c’est qu’un run précédent est mort en cours de route. Le test remet la valeur d’origine avant de commencer son propre travail.
Et il la remet en passant par la vraie interface, comme le ferait un utilisateur. C’est un choix, pas une facilité. Écrire directement en base irait plus vite, mais contournerait tout ce que l’application fait au moment d’un changement de réglage : les contrôles, les recalculs, les mises en cache, les effets de bord. On réparerait la valeur sans réparer l’état, et on se retrouverait avec une incohérence plus difficile à voir que celle qu’on corrigeait.
La conséquence est franche à énoncer :
Un test ne fait plus confiance à la sortie du test précédent. Il nettoie à l’entrée.
L’objection vient toujours, et elle est légitime : si chaque exécution avait son propre compte, le problème disparaîtrait.
La parallélisation est effectivement réglée ainsi, un compte par exécution. Mais cela ne traite pas le partage à l’intérieur d’une même exécution : dès que deux tests se succèdent sur le même compte, le second retrouve le paramètre que le premier n’a pas restauré. L’isolation par compte déplace la frontière, elle ne la supprime pas.
Il faudrait donc un compte par test. C’est jouable quand très peu de tests touchent à ces paramètres et qu’on vérifie, à chaque ajout, qu’ils ne se marchent pas dessus. Cette vérification-là est à refaire indéfiniment, et elle repose sur la vigilance de celui qui écrit le test.
Même dans ce cas, un journal d’état ne coûte rien et ne peut pas nuire.
Peu de choses, et c’est ce qui rend le dispositif intéressant : une fois en place, il demande très peu d’entretien.
Le seul incident que j’ai eu ne venait pas du mécanisme mais de mon propre code. L’ajout d’un paramètre critique d’une nature un peu particulière a demandé d’adapter les mots-clés qui gèrent le journal. Une erreur s’y est glissée, et l’un des paramètres a cessé d’être mis à jour.
La leçon n’est pas très originale, mais elle mérite d’être dite : un journal d’état est de l’infrastructure de test, et l’infrastructure de test se régresse comme le reste. Elle mérite donc ses propres vérifications.
Le teardown reste indispensable. C’est lui qui restaure dès que le test arrive au bout, c’est-à-dire presque toujours, et rien ne le remplace dans ce rôle. Ce qu’il ne peut pas faire, par construction, c’est couvrir les cas où le processus meurt avant lui.
Le journal d’état ne prend pas sa place : il ferme ce trou-là. Et il le ferme avec une garantie d’une autre nature, qui ne dépend plus du bon déroulement de ce qui précède, mais seulement de la capacité du test suivant à lire un fichier avant de commencer.
Un fichier, ça survit.
]]>