Tester une interface iOS avec Dynamic Type sur un Mac distant

Sur l’écran de confirmation d’une commande, l’adresse et le bouton de validation sont entièrement visibles à la taille de texte par défaut. Mais lorsque l’utilisateur agrandit le texte sur son iPhone, la barre fixe en bas de l’écran masque le bouton. Ouvrir la page une seule fois sur une machine de développement ne suffit pas à repérer ce problème : Dynamic Type modifie aussi les retours à la ligne, la hauteur des cellules et la zone de défilement. Voici comment fixer les conditions de test avec un simulateur iOS sur un Mac distant, puis vérifier les parcours essentiels avec des tests d’interface.

Définir l’écran à tester et les critères de réussite

Choisissez un véritable écran au contenu long, comme une confirmation de commande, le détail d’un réglage ou une explication d’erreur. Notez le projet Xcode, le scheme, l’appareil simulé, la version d’iOS utilisée par le simulateur et l’état du compte de test. Les comparaisons ultérieures doivent reprendre exactement ces conditions. Si plusieurs personnes utilisent le même Mac distant, réservez un simulateur à ce test pour qu’une autre tâche ne modifie pas la taille du texte ou n’efface pas les données de l’application.

Listez d’abord les actions qui doivent rester possibles sur cet écran, puis écrivez les assertions. Vérifiez au minimum que le titre est lisible, que le bouton principal est utilisable, que l’on peut faire défiler une longue explication jusqu’au bout et que le retour fonctionne. Constater qu’une vue existe ne prouve pas que son texte n’est pas tronqué.

Décomposez « l’écran semble correct » en un parcours réalisable et des captures à examiner. Les assertions automatiques détectent les défaillances clairement définies ; les captures révèlent les défauts visuels que les assertions ne couvrent pas encore.

Fixer le simulateur et changer la taille du texte

Sur le Mac distant, vérifiez d’abord que les outils en ligne de commande Xcode pointent vers la version attendue, puis listez les appareils disponibles. Ne supposez pas que booted désigne toujours le même appareil : des tâches parallèles sur le même Mac peuvent démarrer plusieurs simulateurs. Inscrivez l’UDID de l’appareil cible dans la configuration de la tâche, démarrez-le et attendez la fin du lancement du système.

xcode-select -p
xcrun simctl list devices available
export SIM_UDID="从上一步选择的设备 UDID"
xcrun simctl boot "$SIM_UDID"
xcrun simctl bootstatus "$SIM_UDID" -b
xcrun simctl help ui

Si l’appareil est déjà démarré, boot indique son état actuel. Après avoir vérifié l’UDID, vous pouvez lancer directement bootstatus. Consultez l’aide des outils installés pour connaître les valeurs de taille de texte acceptées par simctl ui ; ne recopiez pas dans le script des noms de paliers pris dans une autre version de Xcode. Transmettez à la tâche de test une valeur vérifiée dans l’aide locale, par exemple au moyen de la variable d’environnement TEXT_SIZE, puis exécutez :

: "${TEXT_SIZE:?set a supported content size}"
xcrun simctl ui "$SIM_UDID" content_size "$TEXT_SIZE"
xcrun simctl ui "$SIM_UDID" content_size

Testez au minimum la taille par défaut, une taille supérieure et la taille maximale que le produit s’engage à prendre en charge. Ne vérifiez pas uniquement les extrêmes : à un palier intermédiaire, le titre peut gagner une ligne sans que la mise en page prévue pour la taille maximale soit encore déclenchée. Relancez l’application testée après chaque changement pour éviter que l’écran conserve un état mis en cache avant le changement.

Vérifier le parcours avec des tests d’interface

Attribuez des identifiants d’accessibilité stables aux contrôles essentiels de l’application, par exemple checkout.title, checkout.submit et checkout.lastNote. Ils doivent décrire la fonction, et non reprendre le libellé d’un bouton susceptible de changer selon la langue. Le test doit accéder à l’écran de confirmation depuis le même écran initial. Si une connexion ou des données préparées sont nécessaires, utilisez l’environnement de test existant du projet, sans inscrire de véritables identifiants de connexion dans le code de test ni dans les journaux.

Cet extrait XCTest illustre les assertions à prévoir ; adaptez la navigation et l’identifiant de l’état de réussite à votre projet. Pour un écran long, faites d’abord défiler le contenu, puis vérifiez que le dernier paragraphe et le bouton sont utilisables :

let app = XCUIApplication()
app.launch()
let title = app.staticTexts["checkout.title"]
XCTAssertTrue(title.waitForExistence(timeout: 10))

let page = app.scrollViews["checkout.content"]
let lastNote = app.staticTexts["checkout.lastNote"]
for _ in 0..<6 where !lastNote.isHittable {
    page.swipeUp()
}
XCTAssertTrue(lastNote.isHittable)

let submit = app.buttons["checkout.submit"]
for _ in 0..<6 where !submit.isHittable {
    page.swipeUp()
}
XCTAssertTrue(submit.isHittable)
submit.tap()
XCTAssertTrue(app.staticTexts["checkout.success"].waitForExistence(timeout: 10))

Si l’écran n’utilise pas de ScrollView, n’imposez pas ce sélecteur uniquement pour faire passer l’exemple : adaptez-le au conteneur réel. Limiter le nombre de balayages évite que le test attende indéfiniment lorsque la mise en page est défaillante. Toutefois, pouvoir activer un bouton ne prouve pas que son libellé est entièrement visible : conservez aussi une capture d’écran.

Conserver les preuves pour chaque taille et localiser les défauts

Pour chaque palier, consignez l’UDID de l’appareil, la version d’iOS utilisée par le simulateur, la version de Xcode, la taille du texte et le résultat du test. En cas d’échec, enregistrez d’abord les pièces jointes du test d’interface, puis relancez-le au même palier et prenez une capture du simulateur. Incluez le palier et le nom de l’écran dans le nom du fichier pour éviter que des tâches parallèles écrasent leurs captures respectives. En ligne de commande, vous pouvez utiliser xcrun simctl io "$SIM_UDID" screenshot output.png ; dans une véritable tâche, remplacez ce nom de fichier fixe par un chemin de sortie unique.

Pour analyser une capture, commencez par la structure extérieure de la mise en page. Un conteneur de titre à hauteur fixe peut faire disparaître la deuxième ligne ; une étiquette et un montant disposés horizontalement peuvent se disputer la largeur disponible ; un bouton flottant au bas de l’écran peut masquer le dernier paragraphe. Privilégiez un conteneur qui grandit avec son texte, passez si nécessaire les informations d’une disposition horizontale à une disposition verticale et prévoyez un espace sous le contenu défilant. Ne masquez pas un défaut à grande taille en réduisant le texte.

Si le test « réussit parfois », vérifiez d’abord qu’il utilise toujours le même UDID, que l’application redémarre après un changement de palier et que l’assertion ne sélectionne pas par erreur un élément homonyme hors de l’écran. Stabilisez ces conditions avant de modifier la mise en page, pour ne pas prendre un état perturbé du simulateur pour une régression du code.

En faire une liste de contrôle durable

Placez l’appareil, la version d’iOS utilisée par le simulateur et les tailles de texte prises en charge dans la configuration de la tâche, puis exécutez la même suite de tests d’interface à chaque palier. À chaque échec, conservez le palier, l’emplacement de l’assertion et la capture. Après une correction, retestez au minimum le palier concerné et ses paliers voisins. Prévoyez une revue des captures pour les textes tronqués et les chevauchements qui n’ont pas de critère automatique fiable ; ne concluez pas qu’une version est prête à être publiée au seul motif que « l’élément existe ».

Pour finir, parcourez manuellement le chemin le plus important pour l’utilisateur : agrandissez le texte, lisez l’explication jusqu’au bout, trouvez le bouton principal, terminez l’action et revenez à l’écran précédent. L’objectif n’est pas d’obtenir une capture identique à toutes les tailles, mais de permettre, à chaque taille prise en charge, de lire tout le contenu et d’effectuer les actions nécessaires.

Questions fréquentes