Mise à jour produit KENSAI : les preuves des tests de nuit remplacent les métriques rassurantes

Le 26 avril a commencé par le type d’échec qu’un système utile doit conserver au lieu de le lisser : la suite de tests freemium de nuit n’est pas passée. Le point positif, c’est que l’échec est maintenant assez précis pour être corrigé.

Ce que l’exécution nocturne a prouvé

Le reçu cron du 26 avril a enregistré la suite freemium complète de KENSAI depuis le dépôt plateforme. Le résultat n’était pas un vague build rouge. C’était une carte d’échec concrète : pnpm test a quitté avec le code 1 après 636 tests, dont 310 en échec, 243 réussis et 83 ignorés.

La classe d’échec dominante concernait des tests dépendants de l’API qui attendaient un service sur 127.0.0.1:4000 alors que l’API n’était pas disponible, produisant des refus de connexion et des assertions à statut zéro. Ce n’est pas un mystère produit. C’est un défaut de préflight et d’orchestration de service.

Ce qui manquait

Deux autres lacunes ont été consignées au lieu d’être cachées. Le paquet racine ne définissait pas pnpm test:e2e, donc le runner n’avait pas de point d’entrée e2e stable. La commande de couverture a échoué immédiatement parce que @vitest/coverage-v8 manquait. Un repli direct via Playwright a bien démarré, mais le bruit des erreurs d’auth/admin et des timeouts d’une minute le rendait plus honnête à arrêter qu’à interpréter.

Pourquoi c’est une mise à jour produit

Un run de tests en échec n’est pas automatiquement un progrès. Un run en échec avec des comptes, des classes d’erreurs dominantes, des outils manquants et la prochaine voie de réparation, oui. Le système qualité sait désormais distinguer un comportement applicatif défaillant d’une infrastructure jamais démarrée.

C’est important pour KENSAI parce que les affirmations de sécurité côté client reposent sur une vérité opérationnelle assez banale. Si le parcours freemium dépend de l’API, le runner doit la démarrer ou la vérifier avant le départ. Si la couverture est un gate obligatoire, le provider doit être installé. Si l’e2e fait partie du récit de release, il lui faut un vrai script, pas une convention implicite.

Prochaine voie de réparation

La séquence est désormais claire : ajouter ou restaurer un script racine test:e2e, installer le provider de couverture, et faire démarrer puis vérifier l’API sur le port 4000 avant l’exécution des tests dépendants de l’API. Tout le reste serait du théâtre.

C’est la norme que KENSAI devrait garder : conserver la mesure inconfortable, nommer les préconditions cassées, et transformer un run rouge en courte liste de corrections.

En bref

La norme utile est simple : une affirmation devient réelle quand le prérequis, l’artefact et la route s’alignent. Le travail du jour garde cette norme visible.