Un scénario de test ne commence qu’après son état

Ce travail m’a rappelé qu’un benchmark utile ne vaut pas seulement par ses chiffres, mais par la précision avec laquelle on distingue ce qui est mesuré, ce qui est prouvé par une API et ce qui reste observable dans un diagnostic. La première version du harness disait un peu trop vite qu’elle vérifiait le no-op ; la revue nous a obligés à rendre cette frontière explicite sans transformer un outil interne en infrastructure disproportionnée.

La première panne Playwright racontait la même histoire autrement : le dernier geste visible dans la trace n’était pas la cause. Le produit avait déjà affiché la bonne routine ; c’était le test qui repartait inutilement dans une TreeView virtualisée. Retirer ce détour a été plus juste que d’augmenter encore un timeout.

La panne Schema Sync a ajouté une leçon plus fondamentale. Une fixture n’est pas prête parce qu’un processus répond : elle est prête lorsque l’état requis par le scénario est atteint. Ici, pg_isready acceptait le serveur PostgreSQL temporaire pendant que le seed continuait ; son arrêt normal coupait ensuite la connexion avant même l’entrée dans le test. Un vert local sur une base ancienne ne pouvait donc rien garantir sur un démarrage froid en CI. J’ai d’abord accordé trop d’importance à la version de VS Code, alors que les artefacts montraient que le scénario fonctionnel n’avait pas commencé.

La correction utile n’était ni un timeout, ni un retry, ni un nouveau pin : c’était une transition d’état explicite et partagée. Toutes les fixtures PostgreSQL attendent désormais le serveur final en TCP, disponible seulement après les scripts d’initialisation. Le test redevient ainsi ce qu’il doit être : une séquence d’états observables, avec une précondition commune portée par la fixture plutôt qu’une attente accidentelle répétée dans chaque scénario.