iOS-Haptik am Cloud-Mac prüfen: Was Tests leisten und was nicht

Der iOS-Build auf dem Cloud-Mac ist erfolgreich, und auch im Simulator lässt sich die Bestätigungsschaltfläche antippen. Trotzdem kann das Team die Haptik damit noch nicht abnehmen. Der Simulator kann prüfen, ob der Code das richtige Ereignis vorbereitet. Ob sich die Vibration passend anfühlt, können Testende dort nicht beurteilen. Halten Sie beides als getrennte Prüfpunkte fest: den ersten für automatisierte Tests, den zweiten für ein echtes Gerät mit Haptikunterstützung.

Zuerst festlegen, was das Feedback vermitteln soll

Nehmen wir „Speichern abgeschlossen“ als Beispiel: Das Feedback soll einmal ausgelöst werden, nachdem der Speichervorgang erfolgreich war – nicht schon beim Antippen der Schaltfläche. Schlägt das Speichern fehl, muss die Oberfläche einen Fehler anzeigen, darf aber kein Erfolgsfeedback abspielen. Halten Sie vor dem Schreiben der Tests drei Punkte als Vertrag fest: Auslösebedingung, Ereignistyp und Anzahl der Auslösungen.

Haptik darf Text oder einen sichtbaren Status nicht ersetzen. Nutzende können die Systemhaptik deaktiviert haben oder ein Gerät verwenden, das die gewählte Haptikfunktion nicht unterstützt. Das Ergebnis des Speichervorgangs muss immer sichtbar bestätigt werden; die Haptik ergänzt lediglich einen weiteren Wahrnehmungshinweis.

Automatisierte Tests belegen, „welches Feedback angefordert wurde“. Die Abnahme am echten Gerät beantwortet, „ob sich das Feedback passend anfühlt“. Das eine ersetzt das andere nicht.

Ereignisdefinition vom Wiedergabecode trennen

Sind Ereignisparameter über Schaltflächen-Callbacks verteilt, können Tests nur indirekt über die Bedienoberfläche prüfen, was passiert ist. Definieren Sie zuerst eine Funktion, die das Ereignis erzeugt, und lassen Sie anschließend die Wiedergabeschicht darauf zugreifen. So können Tests Anzahl, Typ und relative Zeit der Ereignisse direkt prüfen, ohne von einer spürbaren Vibration abhängig zu sein.

Ereignisse auf dem Cloud-Mac prüfen

Das folgende Beispiel stellt „Speichern abgeschlossen“ durch ein kurzes Ereignis dar. Die Parameter sind ein Ausgangspunkt für das Beispiel, keine Intensitätsempfehlung für jedes Produkt. Die endgültigen Werte müssen am echten Gerät beurteilt werden.

import CoreHaptics

func confirmationEvents() -> [CHHapticEvent] {
    let event = CHHapticEvent(
        eventType: .hapticTransient,
        parameters: [
            CHHapticEventParameter(parameterID: .hapticIntensity, value: 0.65),
            CHHapticEventParameter(parameterID: .hapticSharpness, value: 0.35)
        ],
        relativeTime: 0
    )
    return [event]
}

Im Test-Target des Projekts können Sie zunächst den Vertrag prüfen, der kein Wiedergabegerät benötigt. Test- und Anwendungscode müssen dieselbe Funktion confirmationEvents() verwenden. Erzeugen Sie im Test keine separate Kopie des Ereignisses, da sich die beiden Parametersätze sonst unabhängig voneinander verändern könnten.

import XCTest
import CoreHaptics
@testable import YourApp

final class ConfirmationHapticsTests: XCTestCase {
    func testConfirmationIsOneImmediateEvent() {
        let events = confirmationEvents()
        XCTAssertEqual(events.count, 1)
        XCTAssertEqual(events[0].relativeTime, 0)
        XCTAssertEqual(events[0].eventType, .hapticTransient)
    }
}

Ersetzen Sie YourApp durch den tatsächlichen Modulnamen und führen Sie das Test-Target auf dem Cloud-Mac über den bestehenden gemeinsamen Testablauf des Projekts aus. Geprüft wird hier die Ereignisdefinition; eine echte Vibration im Simulator ist nicht erforderlich. Entscheidet das Produktteam später, aus einem einzelnen Impuls eine zweiteilige Folge zu machen, ändern Sie zuerst den Vertrag und die Tests. Anschließend beurteilen Sie die Wirkung am echten Gerät.

Wiedergabefehler dürfen das Geschäftsergebnis nicht ändern

Die Wiedergabeschicht prüft zuerst CHHapticEngine.capabilitiesForHardware().supportsHaptics und erstellt erst danach Engine und Player. Der Start der Engine, die Erstellung des Patterns oder die Wiedergabe können fehlschlagen. In diesen Fällen wird lediglich ein intern diagnostizierbarer Fehler des haptischen Feedbacks erfasst. Ein bereits erfolgreich abgeschlossener Speichervorgang darf dadurch nicht nachträglich als fehlgeschlagen gelten. Gehen Sie nach einer Unterbrechung der Engine auch nicht davon aus, dass der bisherige Player weiterhin nutzbar ist. Bereiten Sie den Wiedergabestatus entsprechend dem Lebenszyklus der Anwendung erneut vor.

Aufrufzeitpunkt testen, nicht das Gefühl im Simulator

Kapseln Sie den Wiedergabeaufruf hinter einer austauschbaren Schnittstelle. Injizieren Sie in Tests des Speichervorgangs eine Implementierung, die Aufrufe zählt: Nach Erfolg muss genau ein Aufruf erfolgen, nach einem Fehler keiner. Wenn die Geschäftslogik wiederholtes Antippen abfängt, darf dadurch ebenfalls kein zusätzlicher Aufruf entstehen. Testen Sie außerdem den Zweig ohne Haptikunterstützung und prüfen Sie, dass das angezeigte Ergebnis gleich bleibt. Diese Prüfungen sind verlässlicher als die Frage, „ob der Simulator vibriert“, und entsprechen eher dem Verhalten, das der Code tatsächlich garantieren kann.

Erlebnis am echten Gerät abnehmen

Prüfen Sie am echten Gerät mindestens erfolgreiches und fehlgeschlagenes Speichern, schnelle aufeinanderfolgende Aktionen sowie die erste Aktion nach der Rückkehr aus dem Hintergrund. Beobachten Sie, ob Haptik und Abschlussstatus gleichzeitig auftreten und ob die Impulse bei wiederholtem Antippen so dicht aufeinanderfolgen, dass sie kaum noch unterscheidbar sind. Prüfen Sie auch, ob das nächste Feedback nach einer systembedingten Audiounterbrechung oder einem Wechsel der Anwendung in den Hintergrund wieder ordnungsgemäß angefordert werden kann. Ändern Sie beim Abstimmen der Parameter jeweils nur einen Wert. Dokumentieren Sie Testgerät, Systemversion und Beobachtungen, damit subjektive Unterschiede nicht mit Code-Regressionen verwechselt werden.

Auf dem Cloud-Mac lassen sich Build, Simulatortests und Prüfungen des Ereignisvertrags erledigen. Das tatsächliche Empfinden muss das Team weiterhin an einem Gerät mit Haptikunterstützung beurteilen. Eine im Remote-Desktop sichtbare Schaltflächenanimation ist kein Beleg für die Haptikabnahme.

Grenzen vor dem Zusammenführen prüfen

Prüfen Sie vor dem Zusammenführen vier Dinge: Produktionscode und Tests verwenden dieselbe Funktion zur Ereigniserzeugung; ein fehlgeschlagener Speichervorgang löst kein Erfolgsfeedback aus; auch ohne Haptikunterstützung oder bei einem Wiedergabefehler bleibt das Ergebnis eindeutig sichtbar; die Aufzeichnungen vom echten Gerät enthalten Beobachtungen zum Auslösezeitpunkt und zu aufeinanderfolgenden Aktionen. Führt eine Rückmeldung aus dem Gerätetest zur Anpassung eines Parameters, aktualisieren Sie zugleich die Erwartungen im Ereignistest und führen Sie die automatisierten Prüfungen erneut aus.

Mit dieser Aufgabenteilung sichern die Tests auf dem Cloud-Mac reproduzierbare Fakten ab. Die Prüfung am echten Gerät deckt die Erlebnisfragen ab, die der Simulator nicht beantworten kann.

Häufig gestellte Fragen