Enregistrer, revoir et réviser : Automatisation de l’interface utilisateur avec Xcode

Bonjour, je m’appelle Max et je suis ingénieur dans l’équipe Xcode. Xcode regorge de fonctionnalités et d’expériences captivantes, au point de s’y perdre. Savez-vous par exemple qu’un seul clic suffit pour voir votre app s’exécuter sur des dizaines d’appareils, de langues et de configurations ? Vous pouvez aussi obtenir un enregistrement vidéo haute qualité de chaque exécution. Tout cela grâce à l’automatisation de l’interface utilisateur (UI) dans Xcode. Voyons comment cela fonctionne. Commençons par un aperçu de l’automatisation de l’UI. Ensuite, nous préparerons votre app, enregistrerons vos interactions sous forme de code d’automatisation, réexécuterons les tests sur plusieurs appareils et langues, puis visionnerons les résultats en vidéo avec un rapport de succès ou d’échec.

Voyons comment fonctionne l’automatisation de l’UI.

Xcode propose deux frameworks de test : Swift Testing et XCTest. Ces deux frameworks peuvent tester rapidement votre app et son code source dans plusieurs configurations.

Lorsque vous importez XCTest, le framework XCUIAutomation est automatiquement inclus. XCUIAutomation permet d’automatiser votre app et d’interagir avec elle comme le ferait un utilisateur. Ces frameworks forment une suite complète de tests applicatifs, ce que je trouve particulièrement intéressant. Une telle suite combine généralement des tests unitaires et des tests d’automatisation de l’UI. Les tests unitaires vérifient la logique et les modèles de l’app, et grâce à Swift Testing, il est possible de tester des frameworks et des packages Swift sans interface utilisateur. Les tests d’automatisation de l’UI valident également l’expérience utilisateur, l’intégration avec le matériel Apple et le comportement des workflows courants de votre app.

En général, la suite comportera plus de tests unitaires que de tests d’UI, l’objectif étant une couverture complète du code. Les tests d’automatisation de l’UI permettent d’évaluer l’apparence, le comportement et l’intégration de l’app avec le système d’exploitation. Les avantages sont très nombreux.

Par exemple, vous pouvez tester votre app comme un utilisateur, en touchant, balayant ou cliquant. Vous pouvez évaluer son accessibilité par les utilisateurs de technologies d’assistance comme VoiceOver, le contrôle vocal et les polices dynamiques.

Vous pouvez aussi la visualiser dans toutes les langues et zones géographiques qu’elle prend en charge, en vous concentrant sur les langues ayant un fort impact visuel comme les langues avec des chaînes plus longues ou s’écrivant de droite à gauche. Vous pouvez tester son intégration avec le matériel Apple, comme le bouton Action, le déclencheur photo, l’Apple TV Remote et la Digital Crown de l’Apple Watch. Enfin, vous pouvez tester ses performances au lancement, un indicateur clé pour évaluer la rapidité avec laquelle les utilisateurs prennent en main votre app. Configurer un workflow d’automatisation de l’UI comporte trois étapes clés : enregistrer, réexécuter et analyser.

Enregistrez d’abord vos interactions : touchés, balayages, pressions sur des boutons matériels, etc. Regardez Xcode les convertir automatiquement en code. Ensuite, réexécutez-les sur plusieurs appareils et avec différentes langues, zones géographiques et orientations, à la fois sur vos appareils et dans Xcode Cloud. Enfin, examinez les vidéos et les résultats de l’exécution de votre app pour chaque configuration et repérez celles qui ont réussi ou échoué. L’automatisation de l’UI fonctionne sur toutes les plates-formes Apple : iOS, iPadOS, macOS, watchOS, tvOS et visionOS (conçu pour iPad). Une même automatisation peut s’exécuter sur plusieurs plates-formes, ce qui permet de la créer une seule fois pour l’exécuter sur tous vos appareils compatibles. Vous pouvez ainsi voir d’un seul clic comment votre app fonctionne sur Mac, iPhone et Vision Pro, sans modifier le code. Voyons comment l’automatisation de l’UI fonctionne. L’automatisation interagit avec votre app comme un utilisateur, avec des gestes ou des évènements matériels. Elle s’exécute indépendamment de votre app, ce qui empêche l’accès direct aux modèles et données de cette dernière.

Elle indique au système d’exploitation les gestes à effectuer, puis attend de manière synchrone qu’ils s’exécutent un par un.

Ces actions incluent le lancement de l’app, l’interaction avec les boutons et la navigation, la définition de l’état système comme le mode sombre, ou encore la simulation d’un emplacement pour l’appareil. Chez Apple, l’accessibilité est une valeur fondamentale. Nos technologies d’assistance permettent à tous d’utiliser votre app, quelles que soient les déficiences physiques, visuelles, auditives ou motrices. Nous mettons tout en œuvre pour que la plupart de ces technologies fonctionnent avec votre app par défaut, sans effort de développement de votre part. Ajouter un support supplémentaire peut enrichir l’expérience de votre app et faciliter encore plus son automatisation. L’accessibilité constitue la base même de l’automatisation de l’interface utilisateur. Une excellente prise en charge de l’accessibilité garantit une excellente automatisation de l’UI. L’accessibilité fournit directement à l’automatisation des informations comme les types d’éléments, les libellés, les valeurs et les cadres. Mais ce que l’accessibilité voit ne coïncide pas toujours avec la perception humaine. Prenons un exemple. Sur cet écran, le bouton Grande Barrière de corail est visible dans l’UI, mais l’accessibilité voit davantage d’informations. Elle détecte non seulement le type et le libellé des éléments qu’elle expose à l’automatisation de l’UI, mais aussi la propriété identifier. L’identifiant d’accessibilité permet de décrire tout élément à l’écran de manière unique, en fonction des éléments qui l’entourent. Il n’est pas conçu pour être localisé, ce qui permet de référencer le même élément d’UI dans n’importe quelle langue ou sur n’importe quel appareil.

Pour les cases à cocher et autres éléments avec état, une propriété value peut être utilisée. Elle indique l’état actuel de l’élément à la fois pour l’accessibilité et l’automatisation de l’UI.

Pour en savoir plus sur l’accessibilité, consultez « Build accessible apps with SwiftUI and UIKit » (WWDC23) ou « SwiftUI Accessibility: Beyond the basics » (WWDC21).

Maintenant que vous savez comment l’automatisation de l’UI fonctionne avec l’accessibilité, préparons votre app.

Nous allons d’abord ajouter des identifiants d’accessibilité. Puis, nous ferons un rapide examen de l’accessibilité de votre app. Enfin, nous ajouterons une nouvelle cible de test d’UI pour enregistrer nos interactions sous forme de code. Avant de commencer, notez que votre app prend déjà en charge l’automatisation et l’enregistrement de l’UI, sans aucun effort de développement de votre part. Les étapes que nous allons aborder ne sont pas obligatoires, mais elles peuvent améliorer les résultats. L’ajout d’identifiants d’accessibilité peut se faire directement dans votre code SwiftUI, UIKit ou AppKit. Ces identifiants sont le meilleur moyen d’identifier de façon unique un élément de votre app pour l’automatisation. Il est conseillé d’en ajouter aux éléments contenant des chaînes localisées ou du contenu dynamique. Cela inclut le contenu présent dans vos modèles de données ou téléchargé depuis Internet.

Les identifiants pertinents sont uniques dans toute l’app, assez descriptifs pour détailler l’élément concerné, et statiques ; ne changent pas en fonction du contenu.

Même si les titres et les descriptions changent, les identifiants pertinents décrivent toujours le contenu de l’élément associé. Ainsi, nous sommes certains que mes points de repère resteront toujours là.

Dans SwiftUI, vous pouvez ajouter le modificateur accessibilityIdentifier à n’importe quel élément d’UI. Il sera reconnu tant que la vue et ses vues parentes ne seront pas masquées pour l’accessibilité.

Il est conseillé de rendre les identifiants propres à chaque instance de vue, surtout pour les vues utilisées plusieurs fois dans votre app. Ici, nous utilisons la propriété id du point de repère pour rendre chaque identifiant unique.

Dans UIKit, la propriété accessibilityIdentifier s’applique à n’importe quelle UIView, à condition que la vue soit un élément d’accessibilité. Comme la plupart des vues d’UI, tels que les contrôles, textes ou images, le sont par défaut, aucune action n’est généralement nécessaire.

Des propriétés comme accessibilityLabel, accessibilityTraits et accessibilityValue sont utiles aux technologies d’assistance comme VoiceOver, mais aussi à l’automatisation de l’UI.

Toutefois, la propriété accessibilityIdentifier n’est pas lue à haute voix par VoiceOver et n’est pas exposée aux utilisateurs de votre app. Elle ne sert donc qu’à fournir des informations utiles à l’automatisation, telles que l’index d’une cellule de tableau ou le nom de symbole d’une image. Je peux même demander à l’assistant de Xcode d’ajouter les identifiants d’accessibilité. Par exemple, je peux écrire : « Ajoute des identifiants d’accessibilité aux parties pertinentes de cette vue », et il le fera. L’assistant de codage sait même utiliser la propriété id d’un point de repère afin de rendre chaque identifiant totalement unique. Pas mal, non ? Il est judicieux d’examiner le comportement global de l’app pour l’accessibilité avant de lancer l’enregistrement de l’UI. C’est comme passer le fil dentaire avant d’aller chez le dentiste. Vous saurez très vite si vous avez bien fait les choses. Cela vous donnera un bon aperçu de ce qui vous attend. Xcode intègre l’app Accessibility Inspector qui permet de rechercher, diagnostiquer et corriger les problèmes d’accessibilité. Vous pouvez la lancer depuis le menu principal de Xcode, sous Open Developer Tool. Vous pouvez également la lancer depuis Spotlight.

Accessibility Inspector affiche les valeurs d’accessibilité de n’importe quelle vue de votre app, sur n’importe quelle plate-forme. Il suffit de sélectionner la plate-forme à inspecter, de cliquer sur l’inspecteur d’éléments, puis d’interagir avec l’élément d’UI qui vous intéresse. Une liste des propriétés d’éléments apparaîtra. Certaines, comme celles de la section Basique, sont très utiles à l’automatisation de l’UI. Si des informations manquent pour des vues, vous pouvez modifier le code source de votre app pour en ajouter. Vous pouvez consulter les détails de chaque propriété en cliquant sur son nom. Une fenêtre contextuelle vous indiquera quelle propriété définir, avec notamment de la documentation.

Pour approfondir les fonctionnalités d’accessibilité, découvrez notre exemple de code « Delivering an exceptional accessibility experience », qui fournit d’excellents exemples de code pour une app riche en fonctionnalités d’accessibilité et adaptée à l’automatisation de l’UI. Consultez également l’article « Performing accessibility testing for your app » pour découvrir comment tester l’accessibilité de votre app à l’aide de diverses technologies d’assistance. Une fois prêt pour l’automatisation, nous devons ajouter une nouvelle cible de test d’UI pour y placer notre code d’automatisation.

Dans les paramètres du projet Xcode, cliquez sur « + » sous la liste des cibles pour ajouter une nouvelle cible,

puis sélectionnez UI Testing Bundle dans la fenêtre contextuelle.

Cliquez sur Finish. Un nouveau dossier de test d’UI et un modèle sont ajoutés à votre projet. Ce modèle comporte quelques tests simples pour bien démarrer. Nous sommes prêts à enregistrer toutes nos interactions sous forme de code Swift. Utilisons pour cela iOS Simulator et Xcode. Il y a quelques années, ma mère et ma sœur sont parties un mois en Australie sans moi et j’ai été très déçu de ne pas pouvoir les accompagner. Heureusement, je vais pouvoir me rattraper grâce à une app. Je peux utiliser l’exemple de projet Landmarks présenté à la WWDC cette année pour planifier mes vacances. Je vais enregistrer quelques interactions pour planifier mon voyage et m’assurer que ce workflow reste intact dans les futures versions de l’app. La première fois que j’ouvre le fichier source du test d’UI, une fenêtre contextuelle m’indique comment lancer un enregistrement de l’UI. Je lance l’enregistrement en cliquant sur le bouton de la barre latérale, et Xcode compile et relance automatiquement mon app dans Simulator.

Une fois l’app lancée, j’accède à la vue des collections.

À mesure que j’interagis avec l’app, le code pour mes interactions est enregistré dans l’éditeur de code source. Je touche le bouton Plus pour ajouter une nouvelle collection et planifier mon voyage en Australie. Je touche ensuite le bouton Modifier pour renommer le voyage : « Les aventures de Max en Australie ».

Xcode met automatiquement à jour le test lorsque je saisis du texte.

Je vais ensuite éditer la collection de points de repère.

J’ajoute quelques lieux emblématiques comme la Grande Barrière de corail et Uluru, puis je valide.

De retour dans la vue des collections, je constate que ma collection a été ajoutée avec quelques points de repère australiens.

Vous pouvez arrêter l’enregistrement de l’UI en cliquant sur Arrêter l’exécution dans Xcode. Une fois l’enregistrement terminé, il peut être utile de vérifier que l’automatisation a bien capturé ce que vous vouliez. Tout d’abord, vérifiez le code enregistré. Ajoutez ensuite des validations avec les API XCTest pour vérifier que votre app se comporte comme prévu. Enfin, explorez d’autres API d’automatisation qui peuvent rendre vos tests encore plus puissants.

Passons en revue les requêtes d’UI enregistrées pour voir si des ajustements sont nécessaires. Chaque ligne de code enregistré propose plusieurs options pour traiter chaque élément d’UI, et votre choix dépend de vos objectifs. Cliquez sur le menu déroulant de chaque ligne de code source pour voir les possibilités.

Petit conseil : choisir la bonne option vous aidera à embarquer plus vite pour l’Australie !

Voici quelques recommandations pour vous aider à faire le bon choix.

Pour les vues avec des chaînes localisées, comme les textes ou les boutons, choisissez un identifiant d’accessibilité s’il en existe. L’enregistrement de l’UI tente d’utiliser l’identifiant par défaut le cas échéant.

Pour les vues profondément imbriquées, comme du texte dans une vue de défilement, préférez la requête la plus courte possible. Cela garantira la résilience de votre automatisation à mesure que votre app évolue.

Pour le contenu dynamique qui est téléchargé depuis Internet ou change fréquemment, comme les horodatages ou la température, utilisez de préférence une requête plus générique ou un identifiant d’accessibilité, le cas échéant.

Cet exemple n’utilise pas d’identifiant ni de chaîne, et nous nous référons toujours au premier élément de texte.

Passons maintenant à la sélection. Je vais cliquer sur la ligne de code source à modifier pour voir les options. Toutes ces requêtes identifient de façon unique l’élément avec lequel vous avez interagi, il n’y a donc pas de mauvais choix. L’enjeu est de déterminer comment vous voulez référencer cet élément d’UI pour plus tard. Je choisis l’option textFields.firstMatch pour que le champ de texte soit toujours sélectionné dans mon test, quel que soit son nom. Double-cliquez sur un menu déroulant pour enregistrer ce choix dans votre code source. Voyons maintenant si mon automatisation a correctement enregistré mes actions. Je vais cliquer sur le losange de test pour l’exécuter. Nous testons votre app, mais pas votre patience. L’exécution de l’automatisation est ultra rapide !

La collection est rapidement créée avec le nom approprié, les emplacements sont ajoutés et l’automatisation réussit. Génial ! C’était bien plus rapide qu’un vol de 19 heures ! Nous pouvons ajouter des validations au code pour vérifier le comportement attendu. Ici, je vais confirmer que le point de repère Grande Barrière a été ajouté à ma collection.

Je peux appeler des méthodes comme waitForExistence pour que mon automatisation attende l’apparition d’un élément avant de poursuivre. Je peux aussi appeler la méthode plus générique wait(for:toEqual:) pour vérifier qu’une propriété d’un XCUIElement correspond au résultat attendu.

Je peux associer ces deux méthodes avec les instructions XCTAssert de XCTest pour faire échouer le test si elles retournent false.

Je vais revenir à mon code et ajouter un waitForExistence sur le nom de ma collection pour garantir qu’elle est toujours là lors des prochaines exécutions.

C’est le bon moment pour explorer d’autres API d’automatisation afin d’optimiser votre code.

La méthode d’instance setup d’un XCTestCase peut être utile pour s’assurer que l’appareil est dans le même état à chaque exécution. Je peux appeler des API comme orientation et appearance, ou simuler un emplacement pour préparer mon appareil avant l’exécution.

Avant de lancer mon app, je peux utiliser des propriétés comme launchArguments et launchEnvironment pour que mon app utilise ces paramètres lorsque la méthode launch est appelée.

Si l’app prend en charge un schéma d’URL personnalisé, vous pouvez l’ouvrir directement sur une URL correspondante avec la méthode open de XCUIApplication.

Il existe même une version globale qui ouvre une URL avec l’app par défaut de l’appareil.

Enfin, il est possible d’effectuer un audit d’accessibilité de votre app dans un test d’UI. Une excellente séance sur ce sujet intitulée « Perform accessibility audits for your app » a été présentée lors de la WWDC23. Maintenant que les interactions sont enregistrées et l’automatisation en place, configurons les tests pour plusieurs environnements, à la fois sur le bureau et dans le cloud. Il est très utile d’ajouter votre test à un plan de test nouveau ou existant. Les plans de test permettent d’inclure ou d’exclure certains tests, de définir les paramètres système pour contrôler où et comment ils sont exécutés, et de gérer des propriétés comme les délais d’expiration, les répétitions, la parallélisation, l’ordre d’exécution, etc.

Les plans de test sont également associés à un schéma qui vous permet de les lier à des paramètres de build spécifiques.

Pour en savoir plus, consultez l’article « Improving code assessment by organizing tests into test plans » de notre documentation pour développeurs.

Dans votre plan de test, vous pouvez ajouter ou supprimer des tests sur le premier écran ou passer à l’onglet Configurations pour modifier le mode d’exécution du test. Je peux configurer plusieurs variantes pour exécuter mon app dans plusieurs langues.

En règle générale, chaque langue correspond à une configuration distincte dans votre plan de test.

Vous pouvez définir des paramètres centrés sur une configuration de langue spécifique ou des paramètres partagés entre toutes les langues.

Il peut être utile d’inclure des configurations pour les langues avec des chaînes plus longues, comme l’allemand, ou les langues s’écrivant de droite à gauche, comme l’arabe et l’hébreu.

L’onglet Configurations contient des paramètres centrés sur l’automatisation de l’UI.

Vous pouvez ainsi enregistrer une vidéo ou des captures d’écran lors de l’exécution du test, et choisir de conserver ou non les médias.

Par défaut, les vidéos et captures d’écran ne sont conservées que pour les exécutions ayant échoué, afin d’autoriser l’analyse d’éventuels problèmes. Si vous souhaitez les conserver pour toutes les exécutions, y compris celles réussies, sélectionnez « On, and keep all ». Ce paramètre permet de conserver des enregistrements vidéo à des fins de documentation, ou de création de tutoriels ou de contenu marketing. L’onglet Configurations contient une multitude de paramètres intéressants. Pour en savoir plus, consultez « Author fast and reliable tests for Xcode Cloud » (WWDC22).

Xcode Cloud est un service intégré à Xcode, également disponible dans App Store Connect. Il vous permet de générer votre app, d’exécuter des tests, de charger du contenu sur l’App Store, et bien plus encore. Le tout dans le cloud, sans utiliser vos appareils ni ceux de votre équipe. Vous découvrirez rapidement qu’avec Xcode Cloud, tout est simple et fluide ! Pour l’app Landmarks, nous avons configuré un workflow Xcode Cloud qui exécute toutes les nouvelles automatisations d’UI avec le nouveau plan de test. Ce plan fonctionne de la même manière dans le cloud que sur mon simulateur, sur un nombre illimité d’appareils et de configurations comme l’anglais, l’arabe, l’hébreu et l’allemand, sur iPhone et iPad.

Vous pouvez consulter l’historique de vos exécutions Xcode Cloud depuis Xcode ou dans la section Xcode Cloud d’App Store Connect. Vous y trouverez un aperçu des informations de build, journaux, descriptions d’échec, et bien plus encore.

Grâce à Xcode Cloud, toute mon équipe peut voir l’historique de mes exécutions, télécharger les résultats et récupérer les enregistrements vidéo même si je suis dans les nuages, je parle bien sûr de mon vol pour Sydney !

Il reste encore beaucoup à apprendre sur Xcode Cloud. Pour des configurations plus avancées, consultez « Create practical workflows in Xcode Cloud » (WWDC23). Maintenant que nous avons exécuté nos tests enregistrés à l’aide d’un plan de test dans plusieurs configurations, nous pouvons examiner les résultats et les enregistrements vidéo dans le rapport de test. Le rapport de test Xcode propose d’excellents outils pour afficher, comprendre et diagnostiquer les résultats. Il semble qu’une exécution ait échoué à cause de l’automatisation que je viens d’exécuter. Je vais devoir attendre avant de faire mes valises pour l’Australie ! Pour accéder à mon test en échec, je clique sur Test, puis je double-clique sur l’exécution ayant échoué pour voir l’enregistrement vidéo et la description de ce qui s’est passé.

Toutes les exécutions du test apparaissent dans le menu déroulant des exécutions. Cela me permet de basculer rapidement entre les vidéos de mon test dans différentes configurations, comme différentes langues. Notez que je peux télécharger la vidéo en faisant un clic secondaire et en choisissant Save Video.

Pour lire la vidéo, j’appuie sur Lecture.

Lors de la lecture, des points montrant les interactions d’UI s’affichent directement sur la vidéo. Ces actions apparaissent aussi dans la chronologie ci-dessous sous forme de points.

Comme l’échec met un peu de temps à se produire, avançons rapidement. Je vais passer directement au moment de l’échec en utilisant le losange d’échec sur la chronologie.

Un message d’échec apparaît, mais il est difficile d’identifier la cause. Il indique que nous recherchons un bouton intitulé « Les aventures de Max en Australie ». Voyons ce qui était effectivement affiché au moment de l’échec.

Lors de l’échec, je vois une superposition de tous les éléments d’UI présents directement sur l’enregistrement vidéo.

Si je clique sur l’un d’eux, des recommandations de code apparaissent pour traiter cet élément dans mon code d’automatisation. Je peux même cliquer sur Show All pour voir différents exemples et choisir celui qui me convient. Je pense avoir trouvé le problème. Nous attendions un bouton, mais ici il n’y en a pas. Ce n’est que du texte. Corrigeons cela très rapidement.

Je sélectionne l’exemple souhaité et j’effectue un clic secondaire pour le copier.

Ensuite, je clique sur View Source pour accéder directement à mes tests et coller la nouvelle ligne de code sur l’ancienne.

Je remplace la variable XCUIApplication temporaire par la variable app de mon enregistrement de l’UI, et voilà, c’est réglé.

Parfait, maintenant cela devrait fonctionner comme prévu. Je clique sur le losange de test pour relancer l’exécution. Cette fois, je vais exécuter le test en arabe pour vérifier que cette automatisation fonctionne même lorsque mon app s’exécute dans une disposition de droite à gauche.

L’automatisation crée rapidement ma collection et la renomme, comme elle le fait en anglais. Pas mal, non ?

On dirait que l’automatisation est un succès. Il est temps de finir et de partir pour un voyage unique. Peut-être que ma mère et ma sœur pourront m’accompagner pour me servir de guides. Le rapport de test Xcode permet de faire encore bien des choses. Heureusement, la séance « Fix failures faster with Xcode test reports » de la WWDC23 explore le sujet en profondeur. C’est incroyable de voir à quel point l’automatisation de l’UI, l’accessibilité, la localisation, Xcode Cloud et le rapport de test optimisent votre app et la rendent plus accessible à tous et partout dans le monde. Intégrer ces technologies dans un flux unique a été un réel plaisir et j’ai hâte de voir comment les développeurs exploiteront cette nouveauté.

Pour en savoir plus sur les tests unitaires et les tests Swift, regardez la conférence « Meet Swift Testing » de la WWDC24. Si vous avez d’autres questions ou commentaires, retrouvez-nous sur les forums des développeurs. Merci pour votre attention, je vous donne rendez-vous en Australie !