03
Les scénarios qui méritent une régression automatisée
Une exécution d’Intent sans dépendance extérieure
Le premier scénario doit isoler l’exécution elle-même. Le test lance un Intent connu, transmet une valeur fixe et vérifie le résultat attendu. En cas d’échec, consignez la phase précise :
- Intent non découvert par la cible ;
- paramètre trouvé mais impossible à convertir ;
- méthode d’exécution appelée puis interrompue ;
- résultat retourné avec un champ incorrect.
Cette distinction évite de classer tous les problèmes sous « test App Intents échoué ». Une erreur de découverte renvoie plutôt à la cible ou à la configuration, tandis qu’une erreur d’exécution peut venir de la logique métier.
Entity Query, identifiant et transfert entre tâches
Les régressions les plus trompeuses apparaissent souvent dans les Entities. Une requête textuelle peut fonctionner pour un libellé exact, mais échouer avec une variation attendue. Une résolution par identifiant peut également renvoyer une Entity valide avec des champs incomplets. Dans Shortcuts, ces différences se traduisent par une option absente, un mauvais élément sélectionné ou une action suivante impossible à configurer.
Nous vous conseillons de séparer trois assertions :
- la recherche par texte retourne l’Entity de test ;
- l’identifiant de cette Entity permet de la retrouver ;
- les champs exposés correspondent à ceux affichés ou consommés par l’action suivante.
Ajoutez ensuite un scénario composé de deux Intents. Le premier crée ou sélectionne une donnée déterministe ; le second reçoit son résultat comme paramètre. Ce parcours vérifie la compatibilité réelle entre la sortie et l’entrée, au lieu de tester deux fonctions indépendantes.
Les données doivent être créées par le test, porter un identifiant réservé et être supprimées à la fin. Une base personnelle, un compte développeur partagé ou une donnée conservée par un ancien lancement rend le résultat difficile à interpréter.
Spotlight et annotation de l’interface
Spotlight demande une lecture différente du résultat. Une Entity peut être correctement définie dans App Intents tout en étant absente de l’index, périmée ou exposée avec un identifiant incohérent. Il faut donc différencier :
- l’indexation qui n’a jamais eu lieu ;
- l’index qui contient une ancienne représentation ;
- la requête qui filtre incorrectement ;
- l’interface qui n’annotе pas la bonne Entity.
Apple documente la mise à disposition des App Entities dans Spotlight dans ce guide dédié. La référence Core Spotlight permet également de contrôler les mécanismes d’indexation utilisés par l’application.
Pour un test reproductible, initialisez une Entity connue, déclenchez l’indexation attendue, puis recherchez une valeur suffisamment spécifique. Le résultat doit être comparé à l’identifiant et aux champs de l’Entity initialisée. N’utilisez pas une recherche vague qui pourrait réussir grâce à un ancien enregistrement.
Un parcours séparé peut naviguer vers une page déterminée grâce à un Intent de test non exposé aux utilisateurs finaux, puis vérifier l’annotation de la vue. Cela permet de s’assurer que la page rend bien l’Entity attendue, pas seulement un texte visuellement identique.
Cette automatisation couvre le code d’intégration, mais elle ne remplace pas un essai réel avec Siri, une sélection dans Shortcuts ou une recherche Spotlight effectuée dans les conditions normales d’utilisation. La reconnaissance vocale, les formulations ambiguës et la compréhension du contexte doivent encore être évaluées manuellement.
Données isolées et état propre
Un environnement partagé produit des échecs intermittents : une tâche précédente conserve une Entity, deux lancements utilisent le même identifiant, le simulateur garde un état inattendu ou une session utilisateur n’est plus disponible. Pour éviter ces faux diagnostics, chaque test doit pouvoir être lancé seul, après un nettoyage complet, sans supposer qu’un autre scénario a réussi avant lui.
Un Intent de test peut préparer les données, ouvrir une page déterminée et supprimer les ressources créées. Il doit être difficile à découvrir et limité à une configuration de débogage. Avant d’archiver une version de distribution, vérifiez que ce point d’entrée n’est pas inclus dans le produit publié.
Les noms de projet, identifiants, comptes, chemins locaux et exemples de données doivent rester des valeurs neutres telles que ExampleProject, TEAM_PLACEHOLDER ou TEST_ENTITY_ID. Les journaux de CI ne doivent jamais afficher un jeton, une adresse privée ou un identifiant de signature exploitable.
