iOS-Drag-and-Drop-Daten auf einem Cloud-Mac prüfen

Kurz vor dem Release zieht das Team eine Ticketnummer aus einer Liste in einen Editor. Die Drag-Vorschau sieht richtig aus, und beim Ablegen erscheint kein Fehler. Gespeichert wird trotzdem eine leere Zeichenfolge. Die Ursache liegt nicht in der Animation: Wenn der vom Drag-Element deklarierte Datentyp, die vom Drop-Ziel akzeptierten Typen oder der Zeitpunkt des abgeschlossenen asynchronen Ladevorgangs nicht zusammenpassen, kann die Oberfläche einen Erfolg vortäuschen. Bei der Arbeit auf einem Cloud-Mac lässt sich zuerst mit XCTest der Datenvertrag prüfen und anschließend im Simulator die tatsächliche Geste abnehmen. Keiner der beiden Schritte ersetzt den anderen.

Den Drag-and-Drop-Vertrag als prüfbare Vereinbarung festhalten

Halten Sie für jede ziehbare Art von Inhalt drei Dinge fest: den vom Provider deklarierten UTType, die vom Drop-Ziel zugelassenen Typen und den Inhalt, der nach erfolgreichem Laden vorliegen muss. Soll eine Ticketnummer lediglich als Zeichenfolge in ein Textfeld eingefügt werden, können beide Seiten beispielsweise UTType.utf8PlainText vereinbaren. Der Sender darf nicht Klartext registrieren, während der Empfänger nur nach Bildtypen sucht, und ein ausgelöstes Drop-Ereignis darf nicht schon als Erfolg gelten.

Definieren Sie auch die Fehlerpfade: Ein nicht unterstützter Typ darf nicht als zulässiges Drop-Ziel hervorgehoben werden; ein fehlgeschlagener Ladevorgang darf kein leeres Ticket einfügen; ein abgebrochener Drag-Vorgang darf die ursprünglichen Daten nicht verändern. Müssen neben der Ticketnummer weitere Felder erhalten bleiben, definieren Sie ein eigenes Datenformat, das beide Seiten verarbeiten, statt strukturierte Inhalte unbemerkt im Anzeigetext unterzubringen.

Ein abgeschlossener Drop ist ein UI-Ereignis, keine Datenübernahme. Der Anwendungszustand darf erst aktualisiert werden, wenn der Typ passt, das asynchrone Laden erfolgreich war und der Inhalt die Validierung bestanden hat.

Typ und tatsächliche Nutzdaten mit XCTest prüfen

Fügen Sie dem Test-Target der App eine neue Testdatei hinzu. Der folgende Provider registriert UTF-8-Text. Der Test prüft zunächst den Typ, wartet dann auf den Lade-Callback und vergleicht die gelesenen Bytes. Da er weder Maus noch grafischen Desktop benötigt, eignet er sich als schneller Check in der Build-Pipeline.

import XCTest
import UniformTypeIdentifiers

final class DragPayloadTests: XCTestCase {
    func testPlainTextPayload() {
        let provider = NSItemProvider()
        provider.registerDataRepresentation(
            forTypeIdentifier: UTType.utf8PlainText.identifier,
            visibility: .all
        ) { completion in
            completion(Data("ticket-42".utf8), nil)
            return nil
        }

        XCTAssertTrue(provider.hasItemConformingToTypeIdentifier(
            UTType.plainText.identifier
        ))
        XCTAssertFalse(provider.hasItemConformingToTypeIdentifier(
            UTType.image.identifier
        ))

        let loaded = expectation(description: "Load drag payload")
        provider.loadDataRepresentation(
            forTypeIdentifier: UTType.utf8PlainText.identifier
        ) { data, error in
            XCTAssertNil(error)
            XCTAssertEqual(data.flatMap { String(data: $0, encoding: .utf8) },
                           "ticket-42")
            loaded.fulfill()
        }
        wait(for: [loaded], timeout: 5)
    }
}

Hier prüft plainText einen kompatiblen Typ, während utf8PlainText die konkret registrierte Repräsentation lädt. Übernehmen Sie nach einem erfolgreichen Test dieselbe Typprüfung und Dekodierlogik in den Anwendungscode. Andernfalls könnte der Test einen Typ akzeptieren, den die Oberfläche durch eine andere Positivliste ausschließt. Der Produktivcode muss im Callback außerdem error, leere Daten und eine fehlgeschlagene UTF-8-Dekodierung behandeln. Ändern Sie die Oberfläche nicht allein aufgrund von hasItemConformingToTypeIdentifier.

Simulatorziel festlegen und Test ausführen

Prüfen Sie zunächst in der VMCommit-Konsole die aktuell verfügbaren Konfigurationen. Verbinden Sie sich nach der Bereitstellung per SSH mit dem Mac und sehen Sie nach, welche Simulatoren installiert sind. Ersetzen Sie im folgenden Beispiel Projekt, Scheme und Gerätekennung durch Ihre eigenen Werte. Die Gerätekennung stammt aus dem ersten Befehl; die Beispielkennung ist kein reales Gerät.

xcrun simctl list devices available
xcodebuild -list -project App.xcodeproj
xcodebuild test \
  -project App.xcodeproj \
  -scheme App \
  -destination 'platform=iOS Simulator,id=YOUR_DEVICE_ID' \
  -only-testing:AppTests/DragPayloadTests

Der Pfad für -only-testing muss zum Test-Target und Klassennamen im Projekt passen. Meldet der Befehl, dass das Scheme nicht existiert, prüfen Sie zuerst, ob es freigegeben ist. Ist das Zielgerät nicht verfügbar, lesen Sie die lokale Geräteliste erneut aus, statt die Kennung eines anderen Macs zu übernehmen. Bewahren Sie bei einem Testfehler zunächst die unveränderte Ausgabe auf, um „Simulator nicht gestartet“ von „Assertion für die Nutzdaten fehlgeschlagen“ zu unterscheiden.

Das tatsächliche Ablegen in der grafischen Sitzung prüfen

Der Vertragstest umgeht die Gestenverarbeitung. Er beweist daher nicht, dass UIDragInteraction oder UIDropInteraction korrekt eingebunden sind. Öffnen Sie den Simulator auf dem grafischen Desktop, installieren Sie die Test-App und führen Sie einen vollständigen Durchlauf in dieser Reihenfolge aus:

1. Halten Sie ein gültiges Quellelement gedrückt und beginnen Sie zu ziehen. Prüfen Sie, ob die Vorschau zum ausgewählten Element passt.
2. Bewegen Sie es über ein zulässiges Ziel und prüfen Sie dessen Drop-Rückmeldung. Bewegen Sie es anschließend über einen Bereich, der diesen Typ nicht akzeptiert, und prüfen Sie, ob die Rückmeldung verschwindet.
3. Legen Sie das Element ab, warten Sie das Laden ab und prüfen Sie dann, ob die richtige Ticketnummer genau einmal im Editor erscheint.
4. Beginnen Sie einen weiteren Drag-Vorgang und brechen Sie ihn vor dem Ablegen ab. Liste und Editor müssen unverändert bleiben.

Bei größeren Nutzdaten sollte „Wird geladen“ ein eigener Zustand sein: Verhindern Sie doppelte Übernahmen und aktualisieren Sie den Inhalt erst nach Abschluss des Ladevorgangs. Stellen Sie nach einem Fehler die Bedienbarkeit wieder her und zeigen Sie einen eindeutigen Hinweis. Blenden Sie nicht schon vor dem asynchronen Callback „Importiert“ ein, nur damit die Animation flüssiger wirkt. Die grafische Abnahme prüft die für Nutzer sichtbaren Zustandswechsel, XCTest die zugrunde liegenden Daten. Halten Sie beide Ergebnisse getrennt fest.

Fehler entlang des Datenflusses eingrenzen

„Das Ziel wird nicht hervorgehoben“ deutet zunächst auf ein Typenproblem hin: Geben Sie in der Entwicklungsumgebung die vom Sender registrierten und die vom Empfänger zugelassenen Kennungen aus. Prüfen Sie, ob die Typkompatibilität getestet wird, statt lediglich Anzeigenamen zu vergleichen. Bei „Das Ziel wird hervorgehoben, aber es erscheint kein Inhalt“ prüfen Sie als Nächstes, ob der Lade-Callback ausgeführt wird, und untersuchen Fehler, Datenlänge und Dekodierergebnis. Schreiben Sie nicht die gesamten Nutzdaten in gemeinsam genutzte Logs. Ticketinhalte können Geschäftsdaten enthalten; Typ und Länge reichen meist aus, um die Fehlerstelle einzugrenzen.

Wird ein Inhalt „manchmal zweimal eingefügt“, prüfen Sie, ob sowohl der Drop-Callback als auch der Lade-Callback das Modell aktualisieren oder ob derselbe Provider mehrfach zum Laden aufgefordert wird. Weisen Sie jedem Drop eine Vorgangskennung zu und übernehmen Sie das Ergebnis nach erfolgreicher Validierung genau einmal. Verwerfen Sie noch nicht übernommene Ergebnisse bei Abbruch oder Fehler. Wenn Sie auf Bilder oder andere Nutzdaten wechseln, schreiben Sie für jeden akzeptierten Typ eigene Tests. Ein bestandener Klartexttest belegt nicht, dass alle Drag-and-Drop-Pfade funktionieren.

Vor der Bereitstellung zwei Prüflisten abgleichen

Die Prüfliste für die Automatisierung sollte Folgendes abdecken: passende Typen, Zurückweisung nicht unterstützter Typen, übereinstimmende Byte-Inhalte, Behandlung leerer Werte und Lesefehler sowie einen Testfehler bei Zeitüberschreitung. Die Prüfliste für die grafische Abnahme sollte eine korrekte Quellvorschau, die richtige Zielrückmeldung, genau eine Aktualisierung nach Erfolg, unveränderte Inhalte nach Abbruch und Fehlermeldungen ohne fälschliche Erfolgsmeldung enthalten. Die erste Liste eignet sich für jeden Commit; die zweite sollte besonders nach Änderungen an der Interaktion oder der Systemversion erneut geprüft werden.

Wiederholen Sie den Ablauf abschließend auf einem frisch eingerichteten Simulator. So stellen Sie sicher, dass das Ergebnis nicht von Inhalten abhängt, die ein früherer Lauf im Editor hinterlassen hat. Bewahren Sie die im Projekt tatsächlich akzeptierten Typen zusammen mit beiden Prüflisten auf. Bei der nächsten Änderung am Drag-and-Drop-Format lässt sich damit feststellen, ob das Problem im Datenvertrag, beim asynchronen Laden oder bei der Gestenrückmeldung liegt.

Häufig gestellte Fragen