Seed-Daten fuer Tests generieren

1. Warum gute Seed-Daten das Fundament zuverlaessiger Tests sind

Seed-Daten sind der Ausgangspunkt jedes Datenbanktests, und die Qualitaet dieser Daten entscheidet direkt darueber, wie aussagekraeftig ein Test ist. Ein Test, der gegen drei handgepflegte Testzeilen laeuft, findet nur Fehler, die genau diese drei Zeilen betreffen. Sobald in Produktion eine vierte Variante auftaucht, ein leeres Feld, ein Sonderzeichen oder eine ungewoehnliche Kombination aus Fremdschluesseln, ist der Test blind dafuer, weil die Seed-Daten diesen Fall nie abgebildet haben.

Systematisch generierte Seed-Daten loesen dieses Problem, indem sie nicht auf eine feste Handvoll Beispielzeilen setzen, sondern auf ein Skript, das beliebig viele, strukturell vielfaeltige Datensaetze erzeugt. Der Unterschied zwischen manuell gepflegten Fixtures und generierten Seed-Daten ist vergleichbar mit dem Unterschied zwischen Beispiel-basiertem und Property-basiertem Testen: Statt einzelne Faelle zu benennen, wird eine Regel definiert, nach der beliebig viele plausible Faelle entstehen. Die folgenden Abschnitte zeigen, wie sich solche Seed-Daten deterministisch, referenziell korrekt und mit realistischen Randfaellen erzeugen lassen.

Ein weiterer, oft unterschaetzter Effekt guter Seed-Daten ist ihr Einfluss auf die Performance-Aussagekraft von Tests. Eine Abfrage, die gegen zehn Testzeilen in wenigen Millisekunden laeuft, kann gegen realistische Datenmengen einen fehlenden Index oder einen ineffizienten Join-Plan offenlegen, der bei kleinen Datenmengen unsichtbar bleibt. Wer Performance-Regressionen fruehzeitig erkennen will, braucht also nicht nur korrekte, sondern auch ausreichend umfangreiche Seed-Daten, die die Groessenordnung der Produktionsdaten zumindest anteilig widerspiegeln.

2. Synthetische versus anonymisierte Seed-Daten

Es gibt zwei grundsaetzliche Wege, an Seed-Daten zu kommen: sie vollstaendig synthetisch generieren oder eine bestehende Datenmenge, etwa aus Produktion, anonymisieren und wiederverwenden. Synthetische Seed-Daten haben den Vorteil, dass sie ohne jedes Datenschutzrisiko frei geteilt, in offene Repositories eingecheckt und in jeder Umgebung reproduziert werden koennen. Der Nachteil: Sie bilden reale Verteilungen nur so gut ab, wie das Generierungsskript es vorgibt, und uebersehen leicht Muster, die in echten Daten vorkommen, aber niemand explizit modelliert hat.

Anonymisierte Produktionsdaten bilden reale Verteilungen naturgemaess praeziser ab, bringen aber zusaetzlichen Aufwand fuer eine rechtssichere Anonymisierung mit sich und lassen sich schwerer versionieren, weil sie an einen konkreten Snapshot gebunden sind. In der Praxis hat sich ein hybrider Ansatz bewaehrt: synthetische Seed-Daten fuer die tägliche Testentwicklung, ergaenzt durch periodische Tests gegen eine anonymisierte Kopie fuer Performance- und Integritaetspruefungen, die auf echte Datenverteilungen angewiesen sind.

Ein weiterer Faktor bei der Entscheidung ist die Teamgroesse: In kleinen Teams mit direktem Zugriff auf eine gesicherte Produktionsumgebung faellt der zusaetzliche Aufwand einer periodischen Anonymisierung staerker ins Gewicht als in groesseren Organisationen, in denen ohnehin ein dedizierter Datenbank-Verantwortlicher fuer Compliance-Fragen zustaendig ist. Wer extern mit Freelancern oder Agenturen zusammenarbeitet, sollte grundsaetzlich auf synthetische Seed-Daten setzen, um keine echten personenbezogenen Daten ausserhalb der eigenen Infrastruktur weiterzugeben.

3. Deterministische Seed-Daten mit festen Seeds erzeugen

Ein haeufiger Fehler bei generierten Testdaten ist, sie bei jedem Testlauf neu zufaellig zu erzeugen. Das fuehrt zu Flaky Tests, die manchmal fehlschlagen und manchmal nicht, ohne dass sich am Code etwas geaendert hat, nur weil die zufaelligen Seed-Daten diesmal einen Randfall enthielten, den der Test nicht erwartet hat. Die Loesung ist ein fester Zufalls-Seed: Der Zufallsgenerator wird mit einem konstanten Startwert initialisiert, sodass bei jedem Lauf exakt dieselbe Abfolge von scheinbar zufaelligen Werten entsteht.

Mit einem festen Seed werden generierte Testdaten reproduzierbar, ohne die Vielfalt echter Zufallsdaten zu verlieren. Ein fehlgeschlagener Test laesst sich damit exakt nachstellen, weil dieselben Eingabedaten wieder erzeugt werden. Fuer Faelle, in denen bewusst unterschiedliche Datensaetze pro Testlauf gewuenscht sind, etwa fuer Fuzzing, sollte der tatsaechlich verwendete Seed in der Testausgabe protokolliert werden, damit ein fehlgeschlagener Lauf spaeter mit demselben Seed reproduzierbar bleibt.

Ein weiterer Vorteil fester Seeds zeigt sich beim parallelen Testen: Laufen mehrere CI-Jobs gleichzeitig gegen isolierte Testdatenbanken, erzeugt derselbe Seed in jedem Job identische Ausgangsdaten, was Vergleiche zwischen den Jobs erst sinnvoll macht. Ohne festen Seed waere ein Unterschied im Testergebnis zwischen zwei parallelen Jobs nicht eindeutig einem Code-Unterschied zuzuordnen, weil er ebenso gut an unterschiedlichen Zufallsdaten liegen koennte.

-- Deterministic seed data example
-- PostgreSQL: deterministic pseudo-random data with a fixed seed
-- setseed() takes a value between -1 and 1, always yields the same sequence
SELECT setseed(0.42);

INSERT INTO customers (id, email, created_at)
SELECT
  gs                                              AS id,
  'customer' || gs || '@example.test'             AS email,
  NOW() - (random() * INTERVAL '365 days')        AS created_at
FROM generate_series(1, 10000) AS gs;
-- Re-running this script produces the exact same created_at values every time

4. Faker-Bibliotheken und realistische Verteilungen

Faker-Bibliotheken wie faker-js, das PHP-Paket fakerphp/faker oder Pythons Faker generieren plausible Namen, Adressen, E-Mail-Adressen und Freitexte, statt auf generische Platzhalter wie Test1, Test2 zurueckzugreifen. Das ist mehr als Kosmetik: Ein Suchfeature, das gegen ausschliesslich alphabetisch sortierte, gleich lange Testnamen getestet wird, kann Sortier- oder Trunkierungsfehler uebersehen, die bei echten Namen mit Umlauten, Bindestrichen oder unterschiedlicher Laenge auftreten wuerden.

Wichtig ist, ueber reine Namen und Adressen hinauszudenken: Faker-Bibliotheken generieren auch realistische Verteilungen fuer numerische Werte, etwa Bestellsummen nach einer Log-Normal-Verteilung statt einer Gleichverteilung, was der tatsaechlichen Verteilung von Warenkorbwerten deutlich naeher kommt. Wer Seed-Daten mit gleichverteilten Zufallswerten erzeugt, testet ein System gegen eine Datenverteilung, die in Produktion nie auftritt, und uebersieht so Performance-Probleme, die erst bei einer stark schiefen echten Verteilung entstehen, etwa wenige sehr grosse Bestellungen neben vielen kleinen.

Lokalisierte Faker-Provider verdienen besondere Aufmerksamkeit bei international ausgerichteten Anwendungen: Ein deutsches Adressformat unterscheidet sich strukturell von einem US-amerikanischen oder japanischen Format, und ein Seed-Skript, das nur ein Locale abbildet, uebersieht Parsing-Fehler, die erst bei echten internationalen Adressen auftreten. Die meisten Faker-Bibliotheken unterstuetzen mehrere Locales gleichzeitig und lassen sich so konfigurieren, dass generierte Datensaetze zufaellig zwischen ihnen wechseln.

-- PostgreSQL: realistic order amounts via log-normal-like distribution
-- Most orders small, a long tail of large orders — closer to real e-commerce data
INSERT INTO orders (id, customer_id, total_amount, status)
SELECT
  gs,
  (random() * 10000)::int % 10000 + 1,
  ROUND((EXP(RANDOM() * 2.0 + 3.0))::numeric, 2)  AS total_amount,
  (ARRAY['pending','paid','shipped','refunded'])[FLOOR(RANDOM() * 4 + 1)]
FROM generate_series(1, 50000) AS gs;
-- EXP(random * 2 + 3) skews heavily toward smaller values with a long tail

5. Referenzielle Integritaet beim Generieren wahren

Generierte Seed-Daten muessen dieselben Fremdschluessel-Beziehungen einhalten wie echte Produktionsdaten, sonst scheitern Inserts an Constraint-Verletzungen oder erzeugen Test-Setups, die in der realen Welt gar nicht vorkommen koennen. Der zuverlaessigste Ansatz ist, Eltern-Tabellen zuerst zu befuellen und die generierten IDs anschliessend gezielt in die Kind-Tabellen zu uebernehmen, statt Fremdschluesselwerte unabhaengig voneinander zufaellig zu erzeugen.

Ein haeufiger Fehler ist, Fremdschluessel-Spalten mit rein zufaelligen IDs aus dem gesamten moeglichen Wertebereich zu fuellen, ohne zu pruefen, ob diese IDs tatsaechlich in der referenzierten Tabelle existieren. Das funktioniert kurzfristig, wenn Constraints nicht aktiv sind, erzeugt aber Testdaten, die inhaltlich unsinnig sind, etwa Bestellungen mit Kunden-IDs, die nie existiert haben. Seed-Skripte sollten deshalb immer aus tatsaechlich generierten Eltern-Datensaetzen auswaehlen, etwa per ORDER BY RANDOM() LIMIT 1 gegen die bereits befuellte Tabelle, statt komplett unabhaengige Zufallswerte zu verwenden.

Bei mehrstufigen Beziehungen, etwa Bestellungen mit Positionen und Positionen mit Produkten, muss die Generierungsreihenfolge die gesamte Kette respektieren: erst Produkte, dann Bestellungen, dann Bestellpositionen, die auf beide vorherigen Tabellen verweisen. Wird diese Reihenfolge umgedreht, entstehen entweder Constraint-Fehler oder, schlimmer, Seed-Skripte, die Constraints stillschweigend deaktivieren und damit referenziell kaputte Daten erzeugen, die erst in spaeteren Tests unerklaerliche Fehler ausloesen.

-- Correct generation order for a multi-level relationship chain
-- Step 1: parent table first
INSERT INTO products (id, name, price)
SELECT gs, 'Product ' || gs, ROUND((RANDOM() * 100)::numeric, 2)
FROM generate_series(1, 1000) AS gs;

-- Step 2: orders reference existing customers (assumed already seeded)
INSERT INTO orders (id, customer_id, status)
SELECT gs, (SELECT id FROM customers ORDER BY RANDOM() LIMIT 1), 'paid'
FROM generate_series(1, 5000) AS gs;

-- Step 3: order_items reference BOTH orders and products, seeded last
INSERT INTO order_items (order_id, product_id, quantity, unit_price)
SELECT
  (SELECT id FROM orders ORDER BY RANDOM() LIMIT 1),
  (SELECT id FROM products ORDER BY RANDOM() LIMIT 1),
  1 + FLOOR(RANDOM() * 5)::int,
  ROUND((RANDOM() * 100)::numeric, 2)
FROM generate_series(1, 15000) AS gs;

6. Randfaelle und Grenzwerte gezielt erzeugen

Rein zufaellig generierte Seed-Daten decken haeufige Faelle gut ab, uebersehen aber systematisch seltene Randfaelle, weil diese in einer Zufallsverteilung selten genug sind, um bei kleinen Stichproben komplett zu fehlen. Ein robustes Seed-Skript ergaenzt die zufaellig generierte Masse deshalb gezielt um bekannte Grenzwerte: leere Strings, maximale Feldlaengen, NULL-Werte in optionalen Spalten, Datumswerte am Jahreswechsel, negative Zahlen wo eigentlich nur positive erwartet werden, und Unicode-Zeichen ausserhalb des Basic Multilingual Plane wie Emoji.

Diese gezielt eingestreuten Randfaelle sind oft wertvoller als tausende zusaetzliche generische Zeilen, weil sie genau die Stellen testen, an denen Software am haeufigsten bricht. Ein bewaehrtes Muster ist, eine feste Anzahl expliziter Randfall-Zeilen an den Anfang des Seed-Skripts zu setzen, mit sprechenden IDs oder Kommentaren versehen, damit ein Testfehler sofort dem konkreten Randfall zugeordnet werden kann, gefolgt von der grossen Masse zufaellig generierter, aber referenziell korrekter Zeilen.

Ein oft vergessener Randfall betrifft Zeitzonen und Datumsgrenzen: Ein Seed-Datensatz mit einem Zeitstempel exakt um Mitternacht in der Serverzeitzone kann sich in der Anwendungslogik anders verhalten als derselbe Zeitstempel, interpretiert in der Zeitzone eines Nutzers auf einem anderen Kontinent. Wer Seed-Daten gezielt um solche Zeitzonen-Grenzfaelle ergaenzt, deckt Fehler in der Datums- und Zeitverarbeitung ab, die in rein zufaellig verteilten Testdaten praktisch nie zufaellig auftreten.

-- Seed script section: edge cases
-- Explicit edge cases FIRST, clearly labeled, before the bulk random data
INSERT INTO products (id, name, price, description) VALUES
  (1, '',                                  0.00,   NULL),                    -- empty name, zero price, no description
  (2, REPEAT('x', 255),                    999999.99, 'Max length name'),     -- max VARCHAR length boundary
  (3, 'Produkt mit Emoji ???? und Umlaut ä', 19.99,  'Unicode edge case'),     -- non-BMP + umlaut
  (4, 'Negativer Test',                    -1.00,  'Should never be valid'), -- invalid negative price
  (5, 'Jahreswechsel-Produkt',             49.99,  'Created at year boundary');

UPDATE products SET created_at = '2025-12-31 23:59:59' WHERE id = 5;

7. Seed-Skripte versionieren und in CI wiederverwenden

Seed-Skripte gehoeren genauso ins Versionskontrollsystem wie Migrationsskripte, weil sie sich mit dem Schema mitentwickeln muessen. Wird eine Spalte hinzugefuegt oder ein Constraint verschaerft, muss das Seed-Skript synchron aktualisiert werden, sonst schlaegt es beim naechsten Testlauf fehl oder erzeugt Daten, die die neue Constraint nicht abdecken. Ein sinnvolles Muster ist, Seed-Skripte in Versionen zu ordnen, die zu den Schema-Migrationen passen, sodass ein bestimmter Datenbank-Zustand immer mit dem passenden Seed-Skript getestet wird.

In der CI-Pipeline sollte das Seed-Skript nach jeder Migration automatisch laufen, bevor die eigentlichen Tests starten. Das stellt sicher, dass jeder Testlauf auf demselben, bekannten Datenzustand aufsetzt, unabhaengig davon, welcher Entwickler die Pipeline zuletzt ausgefuehrt hat. Wichtig ist, das Seed-Skript idempotent zu gestalten, sodass es auch bei einem bereits teilweise befuellten Test-Schema sauber durchlaeuft, etwa mit TRUNCATE ... CASCADE als erstem Schritt vor dem eigentlichen Insert.

Ein bewaehrtes Namensschema hilft zusaetzlich, Seed-Skripte im Team eindeutig zuzuordnen: ein Praefix mit Datum oder Migrationsversion im Dateinamen zeigt sofort, zu welchem Schema-Stand ein Seed-Skript passt, ohne dass jeder Entwickler den Inhalt einzeln pruefen muss. Bei haeufigen Schema-Aenderungen empfiehlt es sich, alte Seed-Skript-Versionen nicht zu loeschen, sondern archiviert im Repository zu belassen, um Bugreports gegen aeltere Datenbank-Versionen weiterhin reproduzieren zu koennen.

#!/usr/bin/env bash
# ci-seed-and-test.sh — runs after every migration in the CI pipeline
set -euo pipefail

echo "[1/3] Truncating existing seed data (idempotent re-run)"
psql "$DB_URL" -c "TRUNCATE TABLE order_items, orders, products, customers CASCADE;"

echo "[2/3] Loading versioned seed script matching current schema state"
SEED_FILE="./seeds/$(migrate -database "$DB_URL" -path ./migrations version)_seed.sql"
psql "$DB_URL" -f "$SEED_FILE"

echo "[3/3] Running test suite against freshly seeded database"
npm test -- --database-url="$DB_URL"

8. Performance beim Erzeugen grosser Datenmengen

Sobald Seed-Skripte zehntausende oder Millionen Zeilen erzeugen sollen, wird die Performance des Generierungsprozesses selbst zum Thema. Einzelne INSERT-Anweisungen pro Zeile, wie sie viele einfache Faker-Skripte per Default erzeugen, sind fuer grosse Datenmengen ungeeignet, weil jede Anweisung einen eigenen Roundtrip zur Datenbank samt Transaktions-Overhead verursacht. Der deutlich schnellere Weg ist, Werte in Batches zu sammeln und mit Mehrzeilen-INSERT-Anweisungen oder der nativen Bulk-Load-Funktion der Datenbank, etwa COPY in PostgreSQL, einzuspielen.

Ein weiterer haeufig uebersehener Hebel ist, Indizes und Constraints waehrend des Bulk-Inserts temporaer zu deaktivieren und erst danach wieder zu aktivieren, weil jeder Index bei jedem einzelnen Insert mit aktualisiert werden muesste. Bei sehr grossen Seed-Datenmengen lohnt sich zusaetzlich, den Generierungsprozess zu parallelisieren, etwa indem mehrere Batches gleichzeitig gegen unterschiedliche ID-Bereiche laufen, solange die referenzielle Integritaet zwischen den Batches gewahrt bleibt.

Auch die Wahl des Transaktionsrahmens beeinflusst die Performance messbar: Eine einzige grosse Transaktion ueber Millionen Zeilen haelt Undo-Log und Transaktionsspeicher unnoetig lange belegt, waehrend zu kleine Transaktionen mit einem Commit pro Zeile den Overhead durch haeufige Commits summieren. Ein Commit alle paar tausend Zeilen ist in der Praxis meist der beste Kompromiss zwischen Speicherverbrauch und Commit-Overhead, und laesst sich in den meisten Seed-Skripten mit wenigen Zeilen zusaetzlicher Logik umsetzen.

9. Seed-Daten-Strategien im Vergleich

Je nach Testziel eignet sich eine andere Seed-Daten-Strategie besser. Die folgende Tabelle ordnet die wichtigsten Ansaetze nach Aufwand, Reproduzierbarkeit und Aussagekraft ein.

Die Tabelle ist als Entscheidungshilfe gedacht, nicht als starre Regel: Ein Team, das gerade erst mit systematisch generierten Seed-Daten beginnt, sollte zunaechst bei Faker mit festem Seed und einem kleinen Randfall-Katalog starten, bevor es in aufwendigere Strategien wie anonymisierte Produktions-Snapshots investiert.

In der Praxis ergaenzen sich diese Strategien: Faker mit festem Seed liefert die reproduzierbare Masse, gezielte Randfall-Zeilen decken bekannte Grenzwerte ab, und periodische Tests gegen anonymisierte Produktionsdaten validieren, dass die synthetischen Seed-Daten der Realitaet nahekommen. Wer nur auf eine Strategie setzt, riskiert entweder fehlende Reproduzierbarkeit oder fehlenden Realismus.

Bei der Auswahl der passenden Strategie hilft es, das eigene Testziel klar zu benennen: Geht es um funktionale Korrektheit, reicht meist Faker mit festem Seed plus Randfall-Katalog. Geht es um Performance-Validierung vor einem grossen Release, ist der zusaetzliche Aufwand fuer einen anonymisierten Produktions-Snapshot in aller Regel gerechtfertigt, weil sonst Performance-Regressionen erst im Live-Betrieb sichtbar werden.

10. Zusammenfassung

Seed-Daten fuer Tests systematisch zu generieren bedeutet, sich von wenigen handgepflegten Beispielzeilen zu loesen und stattdessen deterministische, referenziell korrekte Datensaetze mit realistischen Verteilungen zu erzeugen. Ein fester Zufalls-Seed macht generierte Daten reproduzierbar. Faker-Bibliotheken liefern plausible Werte statt generischer Platzhalter, und gezielt eingestreute Randfaelle decken die Stellen ab, an denen Software am haeufigsten bricht.

Referenzielle Integritaet, Versionierung im Gleichschritt mit Migrationsskripten und performante Bulk-Inserts machen aus einem einmaligen Skript einen belastbaren, wiederholbaren Teil der CI-Pipeline. Wer synthetische Seed-Daten regelmaessig gegen anonymisierte Produktionsdaten validiert, stellt sicher, dass die generierten Testdaten der Realitaet nahekommen, statt an ihr vorbeizugehen.

Am Ende zahlt sich der anfaengliche Investitionsaufwand in ein durchdachtes Seed-Daten-Skript mehrfach aus: Jeder neue Test, jede neue CI-Pipeline und jeder neue Entwickler im Team profitiert von einer Datenbasis, die weder manuell gepflegt noch bei jedem Lauf neu erfunden werden muss, sondern verlaesslich, dokumentiert und reproduzierbar zur Verfuegung steht.

11. FAQ: Seed-Daten fuer Tests generieren