Automatiser React Native sur iOS quand la source de page est illisible

Réponse courte : les conteneurs imbriqués que vous voyez dans Appium Inspector sont un problème d'outillage, pas un problème React Native. Le testID défini dans votre JSX atteint bien la couche native sur les deux plateformes — il se retrouve simplement enfoui dans une hiérarchie que la plupart des inspecteurs affichent de façon inexploitable. Changez d'outil d'inspection, posez vos testID systématiquement, et un seul localisateur pilotera iOS et Android.

Pourquoi l'arbre iOS ressemble à cela

React Native compose son interface à partir de vues hôtes. Un simple <Pressable> contenant un <Text> peut se traduire par plusieurs nœuds XCUIElementTypeOther imbriqués, dont aucun n'est manifestement « le bouton ». Videz cet arbre et vous obtenez quarante niveaux d'échafaudage : on se rabat alors sur des expressions XPath qui décrivent une position plutôt qu'une identité.

// Fragile : décrit où se trouve l'élément aujourd'hui
driver.findElement(AppiumBy.xpath(
    "//XCUIElementTypeOther[3]/XCUIElementTypeOther[2]/XCUIElementTypeButton[1]"));

Ce localisateur survit exactement jusqu'à ce que quelqu'un ajoute une <View> de mise en page.

Android fait généralement moins mal, car la hiérarchie de vues est plus plate et resource-id offre une prise stable. C'est cette asymétrie qui conduit les équipes à maintenir deux stratégies de localisation pour une seule base de code — et deux fois plus de maintenance.

Le correctif commence dans l'application, pas dans le test

Posez un testID sur chaque élément qu'un test doit toucher. React Native le fait correspondre à l'identifiant d'accessibilité sur iOS et au content-description / resource-id sur Android : la même chaîne fonctionne donc des deux côtés.

<Pressable testID="checkout-button" onPress={checkout}>
  <Text>Check out</Text>
</Pressable>

// Un seul localisateur, deux plateformes
driver.findElement(AppiumBy.accessibilityId("checkout-button")).click();

Deux règles pour que cela tienne dans le temps :

• Nommez le rôle, pas le design. checkout-button, jamais green-cta-v2. Un nom dérivé du design sera nécessairement faux après la prochaine refonte.
• Placez-le sur l'élément pressable, pas sur le libellé. Un testID sur un <Text> à l'intérieur d'un <Pressable> cible le nœud de texte, et un appui dessus peut ne pas être enregistré comme un appui sur le bouton.

Si vous héritez d'une application sans aucun testID, ajoutez-les d'abord aux vingt éléments que touche votre suite de fumée. C'est généralement l'affaire d'un après-midi, et cela élimine l'essentiel du XPath.

Encore faut-il que les identifiants soient visibles

C'est ici que les équipes bloquent. Vous ajoutez correctement vos testID, et l'inspecteur iOS affiche malgré tout un mur de XCUIElementTypeOther. L'identifiant est bien là ; l'outil ne l'expose simplement pas sous une forme exploitable. On en conclut que React Native sur iOS est difficile à automatiser, et l'on retourne au XPath.

Il vaut la peine de confronter cette conclusion à un autre inspecteur avant de reconstruire toute sa stratégie de test autour d'elle. Dans l'inspecteur RobotActions, une application React Native se résout comme n'importe quelle application native — des éléments nommés et adressables plutôt qu'un empilement de conteneurs — ce qui fait toute la différence entre disposer de accessibilityId("checkout-button") ou non.

C'est là toute l'affirmation, et une dizaine de minutes sur l'offre gratuite suffisent à la confirmer ou à l'écarter sur votre propre build.

Vérifiez sur du vrai matériel

Les simulateurs masquent les deux choses les plus susceptibles de casser un écran React Native :

• Le rythme des gestes. Les balayages synthétisés envoient deux coordonnées et sautent tout ce qui se passe entre les deux. Poignées de glissement, carrousels, curseurs et tirer-pour-rafraîchir ne se comportent correctement que sous un flux continu d'événements de pointeur.
• Les boîtes de dialogue système et de permission. Les surcouches Android des constructeurs et les invites de permission iOS surviennent à des moments différents sur un vrai appareil ; un test qui ne les voit jamais passe pour de mauvaises raisons.

Les deux se vérifient facilement une fois l'application installée sur un vrai téléphone que vous pilotez depuis un navigateur.

Un ordre de travail raisonnable

1. Ajoutez des testID aux éléments que touche votre suite de fumée. Des noms fondés sur le rôle.
2. Inspectez sur un vrai appareil iOS et confirmez que les identifiants sont adressables.
3. Remplacez le XPath par accessibilityId partout où l'étape 2 l'a rendu possible.
4. Exécutez la même suite sur Android — la plupart de ces localisateurs devraient fonctionner tels quels.
5. Ne gardez le XPath que pour les rares cas qu'aucune autre approche n'atteint, avec un commentaire expliquant pourquoi.

L'objectif n'est pas zéro XPath. C'est qu'une refonte change la mise en page sans changer les éléments que vos tests savent trouver.

À lire aussi

• Tests React Native sur appareils réels
• Pourquoi votre suite Appium passe au rouge à chaque refonte