iOS-Layouts mit Dynamic Type systematisch prüfen

Bei der Standardschriftgröße zeigt die Bestellbestätigung Adresse und Absenden-Schaltfläche vollständig an. Vergrößert jemand jedoch den Text auf dem iPhone, wird die Schaltfläche von der fixierten Leiste am unteren Bildschirmrand verdeckt. Wer die Seite auf dem Entwicklungsrechner nur einmal öffnet, übersieht das leicht: Dynamic Type vergrößert nicht bloß die Schrift, sondern verändert auch Zeilenumbrüche, Zellenhöhen und den scrollbaren Bereich. Im Folgenden legen wir die Testbedingungen in einem iOS-Simulator auf einem Cloud-Mac fest und prüfen anschließend mit UI-Tests die entscheidenden Bedienabläufe.

Testseite und Erfolgskriterien festlegen

Wählen Sie eine echte Seite mit längerem Inhalt, etwa eine Bestellbestätigung, eine Detailansicht in den Einstellungen oder eine ausführliche Fehlermeldung. Halten Sie Xcode-Projekt, Scheme, Simulatorgerät, iOS-Runtime und Zustand des Testkontos fest. Für spätere Vergleiche müssen dieselben Bedingungen gelten. Wenn sich mehrere Personen den Cloud-Mac teilen, reservieren Sie für diesen Test ein eigenes Simulatorgerät. So kann keine andere Aufgabe die Textgröße ändern oder App-Daten löschen.

Listen Sie zuerst auf, welche Aktionen auf der Seite möglich sein müssen, und formulieren Sie daraus Assertions. Prüfen Sie mindestens, ob die Überschrift lesbar ist, die wichtigste Schaltfläche bedient werden kann, ein langer Hinweis bis zum Ende scrollbar ist und die Zurück-Navigation funktioniert. Allein festzustellen, dass eine Ansicht existiert, beweist noch nicht, dass ihr Text vollständig sichtbar ist.

Zerlegen Sie „sieht gut aus“ in ausführbare Bedienabläufe und Screenshots, die geprüft werden müssen. Automatische Assertions fangen eindeutige Fehler ab; Screenshots zeigen auch visuelle Probleme, für die noch keine Assertion formuliert wurde.

Simulator festlegen und Textgröße wechseln

Prüfen Sie auf dem Cloud-Mac zunächst, ob die Xcode-Kommandozeilentools auf die erwartete Version verweisen, und lassen Sie sich dann die verfügbaren Geräte anzeigen. Verlassen Sie sich nicht darauf, dass booted immer dasselbe Gerät bezeichnet: Bei parallelen Aufgaben können mehrere Simulatoren laufen. Hinterlegen Sie die UDID des Zielgeräts in der Aufgabenkonfiguration und warten Sie nach dem Start, bis das System vollständig hochgefahren ist.

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

Ist das Gerät bereits gestartet, meldet boot seinen aktuellen Status. Prüfen Sie die UDID und führen Sie dann direkt bootstatus aus. Welche Werte simctl ui für die Textgröße akzeptiert, entnehmen Sie der Hilfe der installierten Tools. Übernehmen Sie keine Stufenbezeichnungen aus Skripten für eine andere Xcode-Version. Geben Sie der Testaufgabe einen lokal anhand der Hilfe geprüften Wert mit, beispielsweise über die Umgebungsvariable TEXT_SIZE, und führen Sie dann Folgendes aus:

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

Testen Sie mindestens die Standardstufe, eine größere Stufe und die größte Stufe, deren Unterstützung das Produkt zusagt. Prüfen Sie nicht nur die beiden Extreme: Bei einer Zwischenstufe kann die Überschrift gerade eine zusätzliche Zeile beanspruchen, ohne dass bereits das für die größte Schrift vorgesehene Layout greift. Starten Sie die zu testende App nach jedem Wechsel neu, damit die angezeigte Seite nicht noch den Zustand vor dem Wechsel enthält.

Bedienabläufe mit UI-Tests prüfen

Vergeben Sie in der App stabile Accessibility-IDs für wichtige Bedienelemente, etwa checkout.title, checkout.submit und checkout.lastNote. Die IDs sollten die Funktion bezeichnen und nicht vom Wortlaut einer Schaltfläche abhängen, der sich je nach Sprache ändert. Der Test soll die Bestellbestätigung stets von derselben Ausgangsseite aus öffnen. Sind eine Anmeldung oder vorbereitete Daten nötig, nutzen Sie die vorhandene Testumgebung des Projekts. Schreiben Sie keine echten Zugangsdaten in Testcode oder Logs.

Der folgende XCTest-Ausschnitt zeigt die Richtung der Assertions. Passen Sie die Navigation und die ID für den Erfolgszustand an Ihr Projekt an. Scrollen Sie auf einer langen Seite zuerst und prüfen Sie danach, ob der letzte Abschnitt und die Schaltfläche bedienbar sind:

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))

Wenn die Seite keine ScrollView verwendet, erzwingen Sie nicht den Selektor aus dem Beispiel, nur damit der Test besteht. Passen Sie ihn an den tatsächlichen Container an. Eine Obergrenze für die Scrollversuche verhindert, dass der Test bei einem defekten Layout endlos wartet. „Antippbar“ beweist allerdings noch nicht, dass die Schaltflächenbeschriftung vollständig sichtbar ist. Bewahren Sie deshalb auch Screenshots auf.

Ergebnisse je Textstufe sichern und Fehler eingrenzen

Halten Sie für jede Stufe Geräte-UDID, Runtime, Xcode-Version, Textstufe und Testergebnis fest. Sichern Sie bei einem Fehler zunächst die Anhänge des UI-Tests. Wiederholen Sie den Lauf dann mit derselben Textstufe und erstellen Sie einen Simulator-Screenshot. Nehmen Sie Stufe und Seitenname in den Dateinamen auf, damit parallele Aufgaben ihre Bilder nicht gegenseitig überschreiben. Für einen Screenshot über die Kommandozeile können Sie xcrun simctl io "$SIM_UDID" screenshot output.png ausführen; in der eigentlichen Testaufgabe sollten Sie den festen Dateinamen durch einen eigenen, eindeutigen Ausgabepfad ersetzen.

Suchen Sie beim Prüfen des Screenshots zuerst in den äußeren Layout-Containern nach der Ursache. Ein Überschriften-Container mit fester Höhe lässt oft die zweite Textzeile verschwinden. Nebeneinander angeordnete Beschriftungen und Beträge konkurrieren um Breite. Eine schwebende Schaltfläche am unteren Bildschirmrand kann den letzten Absatz verdecken. Lassen Sie den Container des Textes nach Möglichkeit mit seinem Inhalt wachsen. Ordnen Sie Informationen bei Bedarf untereinander an und lassen Sie am Ende des scrollbaren Inhalts Platz frei. Kaschieren Sie Fehler bei großen Schriftgrößen nicht durch kleinere Schrift.

Wenn ein Test „manchmal besteht“, prüfen Sie zuerst, ob er stets dieselbe UDID verwendet, ob die App nach dem Wechsel der Textstufe neu gestartet wird und ob die Assertion versehentlich ein gleichnamiges Element außerhalb des Bildschirms auswählt. Ändern Sie das Layout erst, wenn die Testbedingungen stabil sind. Sonst könnten Sie einen veränderten Gerätezustand fälschlich für eine Code-Regression halten.

Eine dauerhaft nutzbare Checkliste erstellen

Hinterlegen Sie Gerät, Runtime und unterstützte Textstufen in der Konfiguration der Testaufgabe und führen Sie dieselben UI-Tests für jede Stufe aus. Bewahren Sie bei jedem Fehler die Textstufe, die fehlgeschlagene Assertion und den Screenshot auf. Prüfen Sie nach jeder Korrektur mindestens die betroffene und die benachbarten Stufen erneut. Wo sich abgeschnittener Text oder Überlappungen nicht zuverlässig automatisch erkennen lassen, planen Sie eine Sichtprüfung der Screenshots ein. Aus „Element vorhanden“ allein folgt keine Freigabe für die Veröffentlichung.

Gehen Sie zum Schluss den wichtigsten Bedienablauf von Hand durch: Text vergrößern, den Hinweis bis zum Ende lesen, die Hauptschaltfläche finden, die Aktion ausführen und zurückkehren. Ziel sind nicht identische Screenshots bei allen Schriftgrößen. Entscheidend ist, dass sich die Inhalte bei jeder unterstützten Größe vollständig lesen und die Aktionen weiterhin ausführen lassen.

Häufig gestellte Fragen