Wie verwaltest du Testdaten, damit Tests über Läufe und Umgebungen hinweg zuverlässig bleiben?

Lass jeden Test die Daten anlegen, die er braucht, und danach aufräumen, mit eindeutigen Kennungen, damit parallele Läufe nicht kollidieren. Bau Daten lieber über die API oder Factories als über eine geteilte geseedete Datenbank, denn geteilte Fixtures verrotten und erzeugen versteckte Kopplung zwischen Tests. Häng nie von Daten ab, die jemand manuell geladen hat, und verlass dich nie auf unmaskierte Produktionsdaten mit personenbezogenen Informationen.

Das Ziel ist, dass jeder Test allein, in beliebiger Reihenfolge und parallel zu den anderen laufen und trotzdem bestehen kann. Das schließt einen geteilten geseedeten Datensatz aus, der immer ordentlich startet und binnen zwei Monaten ein Sumpf ist, weil niemand weiß, welcher Test von welcher Zeile abhängt. Also baut sich jeder Test, was er braucht, idealerweise über API-Aufrufe oder einen Factory-Helper statt über die UI, was schneller und weit weniger brüchig ist. Jeder Datensatz bekommt eine eindeutige Kennung, meist eine Lauf-ID plus Zeitstempel in der E-Mail oder im Namen, damit sich zehn parallele Worker nicht um denselben Account streiten. Aufgeräumt wird im Teardown, aber ich entwerfe so, dass übrig gebliebene Daten harmlos sind, statt anzunehmen, dass das Aufräumen immer läuft, denn bei einem abgestürzten Test tut es das nicht. Deshalb gibt es zusätzlich einen geplanten Job, der alles älter als einen Tag löscht, das dem Testnamensmuster entspricht. Bei Produktionsdaten wehre ich mich stark gegen unmaskierte Kopien. Brauchen wir realistisches Volumen und realistische Form, will ich sie generiert oder ordentlich anonymisiert, denn eine Testumgebung voller echter Kundendatensätze ist ein Datenleck mit Anlauf und hat meist schwächere Zugriffskontrollen als die Produktion.