Vérifier le retour haptique iOS sur un Mac cloud, sans surestimer le simulateur

La compilation iOS passe sur un Mac cloud et le bouton de confirmation fonctionne dans le simulateur. L’équipe ne peut pourtant pas considérer la validation du retour haptique comme terminée. Le simulateur permet de vérifier que le code prépare le bon événement, mais pas de ressentir la vibration. Il faut donc en faire deux contrôles distincts : confier le premier à l’automatisation et réserver le second à un appareil réel compatible avec le retour haptique.

Définir d’abord ce que le retour doit signifier

Prenons « enregistrement terminé » comme exemple. Le retour doit se déclencher une fois, après la réussite de l’enregistrement, et non dès que l’utilisateur appuie sur le bouton. Si l’enregistrement échoue, l’interface doit afficher une erreur sans jouer le retour de réussite. Avant d’écrire les tests, consignez trois éléments du contrat : la condition de déclenchement, le type d’événement et le nombre de déclenchements.

Le retour haptique ne doit pas remplacer un texte ou un état visuel. L’utilisateur peut avoir désactivé les vibrations du système ou utiliser un appareil qui ne prend pas en charge la capacité haptique choisie. Le résultat de l’enregistrement doit toujours être confirmé visuellement ; le retour haptique n’est qu’un indice perceptible supplémentaire.

Les tests automatisés prouvent « quel retour a été demandé » ; la validation sur appareil réel détermine « si ce retour convient ». Aucun des deux ne remplace l’autre.

Séparer la spécification de l’événement du code de lecture

Si les paramètres de l’événement sont dispersés dans les callbacks des boutons, les tests ne peuvent déterminer ce qui s’est produit qu’indirectement, en interagissant avec l’interface. Créez d’abord une fonction qui génère les événements, puis faites-la utiliser par la couche de lecture. Les tests pourront ainsi vérifier directement leur nombre, leur type et leur chronologie relative, sans dépendre d’une vibration matérielle.

Exécuter les contrôles d’événements sur un Mac cloud

L’exemple suivant représente « enregistrement terminé » par un événement bref. Ses paramètres sont un point de départ, pas une intensité recommandée pour tous les produits ; les valeurs définitives doivent être validées à l’usage sur un appareil réel.

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]
}

Dans la cible de test du projet, commencez par vérifier le contrat qui ne dépend pas d’un appareil capable de jouer le retour. Les tests et l’application doivent appeler la même fonction confirmationEvents() : ne recréez pas les événements dans les tests, sous peine de voir les deux jeux de paramètres diverger.

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

Après avoir remplacé YourApp par le nom réel du module, exécutez cette cible sur le Mac cloud à l’aide du point d’entrée de test partagé déjà prévu dans le projet. Ce contrôle porte sur la définition de l’événement ; il n’exige pas que le simulateur produise une véritable vibration. Si les besoins métier conduisent ensuite à remplacer ce retour unique par une séquence en deux temps, modifiez d’abord le contrat et les tests, puis évaluez le ressenti sur appareil réel.

Un échec de lecture ne doit pas changer le résultat métier

La couche de lecture vérifie d’abord CHHapticEngine.capabilitiesForHardware().supportsHaptics, puis crée le moteur et le lecteur. Le démarrage du moteur, la création du motif ou la lecture peuvent échouer. La branche d’erreur doit seulement consigner un échec du retour, exploitable pour le diagnostic interne ; elle ne doit pas requalifier en échec un enregistrement déjà réussi. Après une interruption du moteur, ne supposez pas non plus que l’ancien lecteur reste utilisable : préparez de nouveau l’état de lecture selon le cycle de vie de l’application.

Tester le moment de l’appel, pas le ressenti dans le simulateur

Placez l’action de lecture derrière une interface remplaçable. Dans les tests du flux d’enregistrement, injectez une implémentation qui compte les appels : vérifiez qu’il y en a un après une réussite et aucun après un échec. Si la logique métier bloque les appuis répétés, elle ne doit pas non plus déclencher de lectures supplémentaires. Testez séparément le cas où l’appareil ne prend pas en charge le retour haptique, pour confirmer que le résultat affiché ne change pas. Ces contrôles sont plus stables que la question « le simulateur vibre-t-il ? » et correspondent mieux à ce que le code peut réellement garantir.

Réserver la validation du ressenti à un appareil réel

Les vérifications sur appareil réel doivent couvrir au minimum la réussite et l’échec de l’enregistrement, les actions rapides et répétées, ainsi que la première action après un retour de l’arrière-plan. Observez si le retour haptique et l’état « terminé » surviennent en même temps ; si les retours deviennent difficiles à distinguer lors d’appuis successifs ; et si le retour suivant peut encore être demandé après une interruption audio par le système ou un passage de l’application en arrière-plan. Ne modifiez qu’un paramètre à la fois et consignez l’appareil de test, la version du système et les observations, afin de ne pas confondre des différences de ressenti avec une régression du code.

Un Mac cloud permet de compiler, d’exécuter les tests sur simulateur et de vérifier le contrat des événements. Le ressenti doit néanmoins être confirmé par l’équipe sur un appareil compatible avec le retour haptique : l’animation d’un bouton visible dans un bureau distant ne constitue pas une preuve de validation haptique.

Vérifier les limites avant de fusionner

Avant la fusion, vérifiez quatre points : le code de production et les tests utilisent la même fonction de génération des événements ; un échec de l’enregistrement ne déclenche pas le retour de réussite ; le résultat reste clairement visible si le retour haptique n’est pas pris en charge ou si sa lecture échoue ; et les observations sur appareil réel précisent le moment du déclenchement ainsi que le comportement lors d’actions répétées. Si un retour issu des essais sur appareil réel conduit à ajuster les paramètres, mettez aussi à jour les attentes des tests d’événements, puis relancez les contrôles automatisés.

Avec cette répartition, les tests sur Mac cloud protègent les faits reproductibles, tandis que les vérifications sur appareil réel couvrent les questions d’expérience auxquelles le simulateur ne peut pas répondre.

Questions fréquentes