test: zwei bekannte Flakes entschärfen - #76
Merged
Conversation
1) Kollisionstests (booking/beleg): toBe(5000) prueft die falsche Zusage. Die Eindeutigkeit garantiert nicht der Generator, sondern UNIQUE + Retry in booking-core.ts. Bei 40 Bit Entropie liegt die Kollisionswahrscheinlichkeit ueber 5000 Ziehungen bei rund 1:88.000 pro Lauf — der Test waere im Schnitt alle 88.000 Laeufe grundlos rot geworden. Jetzt >= 4995: laesst einzelne Kollisionen zu, schlaegt aber an, wenn die Streuung zusammenbricht. 2) hookTimeout global auf 60 s. Die beforeAll-Hooks der Integrationstests werfen das Schema weg und fahren die ganze Migrationskette hoch; deren Dauer waechst mit jeder Migration, der Standard-Timeout nicht. email-change.test.ts lief deshalb sporadisch in einen Timeout, einzeln aber gruen. Beides ist dieselbe Sorge: Ein roter Lauf ohne echten Fehler wird beim naechsten Mal weggeklickt — und dann faellt ein echter Fehler auch nicht mehr auf. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018YNj1kkesDywuEGvNweBHM
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Räumt die beiden „kleineren offenen Punkte" aus
docs/STATUS.mdab.1. Kollisionstests prüften die falsche Zusage
booking.test.ts:63undbeleg.test.ts:62erwartetentoBe(5000)— also null Kollisionen über 5000 Ziehungen.Das ist aus zwei Gründen falsch:
UNIQUE+ Retry inbooking-core.ts:196(fünf Versuche mitonConflictDoNothingauf den Code-Constraint). Der Test prüfte einen Vertrag, den die getestete Funktion nie versprochen hat.Jetzt
toBeGreaterThanOrEqual(4995): lässt einzelne Kollisionen zu, schlägt aber weiterhin an, wenn die Streuung wirklich zusammenbricht. Der Produktivcode bleibt unverändert — er war in Ordnung.2.
hookTimeoutglobal auf 60 semail-change.test.tslief sporadisch in einenbeforeAll-Timeout, einzeln aber grün. Der Hook wirft das Schema weg und fährt die gesamte Migrationskette neu hoch — die Dauer wächst mit jeder Migration, der Standard-Timeout von 10 s aber nicht. Mit Migration 0039 kommt die nächste dazu.Gesetzt wird das zentral in
vitest.config.ts, nicht in der einen Datei: Jede Integrationstest-Datei mit Schema-Reset hat dieselbe Exposition.Warum das kein Kosmetikpunkt ist
Beide Fälle sind dieselbe Sorge: Ein roter Lauf ohne echten Fehler wird beim nächsten Mal weggeklickt — und dann fällt ein echter Fehler auch nicht mehr auf. Das ist in diesem Repo schon einmal passiert (falsches CI-Rot am 27.07.).
Geprüft
booking.test.ts,beleg.test.tsundemail-change.test.tszusammen: 39 Tests grün.🤖 Generated with Claude Code
https://claude.ai/code/session_018YNj1kkesDywuEGvNweBHM