Database Seeding – Testdaten sauber für Dev und CI erzeugen

Leere Datenbanken sind selten hilfreich: Eine Login-Maske ohne Nutzer, ein Dashboard ohne Einträge oder ein Shop ohne Produkte liefert kaum Feedback. Genau hier setzt Database Seeding an: Es füllt eine Datenbank gezielt mit Start- oder Testdaten, damit Entwicklung, Demos und automatisierte Tests realistisch laufen. Entscheidend ist nicht „möglichst viele Daten“, sondern Daten, die die wichtigen Fälle abdecken und sich jederzeit reproduzierbar erzeugen lassen.

Database Seeding verstehen: Wofür Seed-Daten wirklich genutzt werden

Seed-Daten sind vorbereitete Datensätze, die per Skript in die Datenbank geschrieben werden. Typische Einsätze:

• Testdaten für lokale Entwicklung: UI und Features lassen sich sofort ausprobieren.
• Stabile Ausgangslage für Integrationstests in der CI (Continuous Integration).
• Daten für Staging/Review-Apps, damit Fachbereiche Features beurteilen können.
• „Basisdaten“ wie Länderlisten, Rollen oder Konfigurationen (oft dauerhaft nötig).

Wichtig ist die Trennung: Manche Daten sind produktionsnah und „echt“ (z. B. Rollen), andere sind nur zum Testen da (z. B. 50 Beispielkunden). Beides wird oft in unterschiedlichen Seed-Schritten gepflegt.

Seed-Daten vs. Migrations: Saubere Aufgabenteilung

Migrations ändern das Schema (Tabellen, Spalten, Constraints). Seeds füllen Inhalte. Beides sollte klar getrennt bleiben, weil sonst bei jeder Schema-Änderung auch Datenlogik „aus Versehen“ mitwandert.

Wer tiefer in Schema-Änderungen einsteigen will, kann das Prinzip in Database Migrations verstehen – Schema-Änderungen ohne Chaos nachlesen.

Reproduzierbarkeit: Der wichtigste Qualitätsfaktor

Seed-Daten müssen wiederholbar sein. Wenn ein Seed-Lauf heute 20 Kunden erzeugt und morgen 18 (weil zufällige Generatoren anders laufen), entstehen schwer nachvollziehbare Fehler. Besonders in CI führt das zu flackernden Tests (Tests, die ohne Code-Änderung mal grün und mal rot sind).

Seed-Strategie planen: Welche Daten braucht das Team wirklich?

Bevor Code geschrieben wird, lohnt sich ein kurzer Plan. Im Alltag helfen drei Datensorten:

• Basisdaten: seltene Änderungen, klare Werte (z. B. Rollen, Statuslisten).
• Realistische Beispieldaten: genug, um Listen/Filter/Pagination zu testen.
• Gezielte Kantenfälle: Dinge, die häufig kaputtgehen (z. B. „Kunde ohne Adresse“, „Bestellung ohne Positionen“).

Realistisch, aber nicht „zu echt“

Seed-Daten sollten produktionsähnliche Strukturen haben (z. B. 1:n-Beziehungen), aber keine echten personenbezogenen Daten enthalten. Auch in Staging sollten keine kopierten Kundendaten landen. Besser sind generierte Namen/Emails oder neutrale Dummy-Werte.

Idempotent oder bewusst „resetbar“?

Es gibt zwei gängige Wege:

• Idempotent: Ein Seed kann mehrfach laufen, ohne Duplikate zu erzeugen (z. B. per Upsert/„find-or-create“).
• Reset-Ansatz: Vor dem Seeding wird die Datenbank geleert und danach neu befüllt (sehr praktisch lokal und in CI).

Für CI ist der Reset-Ansatz oft am stabilsten, weil jede Pipeline mit exakt derselben Ausgangslage startet. Lokal kann beides sinnvoll sein: Reset für schnelle „frisch starten“-Workflows, idempotent für Basisdaten.

Seed-Daten implementieren: Muster, die langfristig wartbar bleiben

Ein gutes Seed-Setup ist weniger ein einzelnes Skript, sondern eine kleine Struktur aus klaren Bausteinen:

• Ein Einstiegspunkt (z. B. seed), der Teil-Seeds in Reihenfolge aufruft.
• Separate Module/Dateien pro Bereich (Users, Produkte, Bestellungen).
• Hilfsfunktionen für wiederkehrende Muster (z. B. zufällige, aber deterministische Daten).

Reihenfolge und Beziehungen: Erst „Eltern“, dann „Kinder“

Typischer Ablauf bei relationalen Datenbanken:

• Rollen/Permissions
• Nutzer
• Produkte
• Bestellungen (mit Bestellpositionen)

Damit Foreign Keys (Fremdschlüssel) nicht scheitern, müssen referenzierte Datensätze vorher existieren. Alternativ können Seeds auch mit temporär deaktivierten Constraints arbeiten – das ist aber riskanter und sollte eher die Ausnahme bleiben.

Deterministische Zufallsdaten: Gleiche Seeds, gleiche Daten

„Zufällige“ Daten sind hilfreich, solange sie reproduzierbar sind. Viele Teams lösen das so:

• Ein fester Seed-Wert für den Zufallszahlengenerator (z. B. über eine Umgebungsvariable).
• Eine definierte Anzahl Datensätze pro Tabelle.
• Klare Regeln für Formate (Emails, Telefonnummern, Statuswerte).

So entsteht Varianz, ohne dass ein Lauf unvorhersehbar wird.

Seed-Daten in Dev, Staging und CI: Unterschiede, die zählen

Ein häufiger Fehler ist „ein Seed für alles“. In der Praxis unterscheiden sich Anforderungen je Umgebung.

Lokale Entwicklung: schnell, flexibel, optional groß

Lokal zählt Geschwindigkeit. Ein schlanker Default-Seed sollte in kurzer Zeit ein nutzbares System erzeugen. Für Performance-Tests kann es zusätzlich einen „Large Seed“ geben, der viele Datensätze generiert.

Wenn im Projekt Umgebungsvariablen genutzt werden (z. B. um Seed-Modi zu schalten), hilft eine saubere Basis: Environment Variables verstehen – .env sicher nutzen.

CI-Pipeline: klein, stabil, testfokussiert

In CI sollte das Seed-Set so klein wie möglich sein, aber alle Tests zuverlässig unterstützen. Typischer Ansatz:

• Datenbank wird frisch erstellt oder zurückgesetzt.
• Migrations laufen.
• Seed-Lauf erzeugt ein minimales, aber vollständiges Dataset.
• Tests laufen gegen diese definierte Ausgangslage.

Wer mit APIs testet, sollte außerdem vermeiden, dass Seeds zufällig unterschiedliche Statuscodes oder Fehlersituationen erzeugen. Eine konsistente Fehlerbehandlung hilft auch unabhängig vom Seeding, z. B. in API-Fehler richtig behandeln – robuste Webanwendungen Schritt für Schritt.

Staging/Review: realistisch für Demos, aber kontrolliert

Staging braucht oft mehr „Story“: verschiedene Nutzerrollen, beispielhafte Bestellverläufe, leere und volle Zustände. Gleichzeitig sollten Seeds dort kontrolliert bleiben, damit Demos nicht durch zu viele Daten unübersichtlich werden.

Typische Stolperfallen beim Seeding – und wie sie vermieden werden

Duplikate und inkonsistente Zustände

Wenn Seeds mehrfach laufen, entstehen schnell doppelte Einträge. Abhilfe:

• Unique-Constraints nutzen und im Seed gezielt upserten.
• Vorher löschen (Reset-Ansatz) oder mit klaren IDs/Keys arbeiten.
• Seeds nach Bereichen trennen (Basisdaten getrennt von Beispieldaten).

Seed-Daten passen nicht zum Validierungs-Code

Wenn die Anwendung Eingaben validiert (z. B. „Email muss eindeutig sein“), müssen Seeds dieselben Regeln einhalten. Sonst wirkt der Seed „kaputt“, obwohl die App korrekt ist. Praktisch ist, Validierungsregeln in Hilfsfunktionen wiederzuverwenden oder mindestens Formate zentral zu definieren.

Zu große Seeds machen Entwicklung langsam

Viele Datensätze wirken realistisch, bremsen aber jeden Neustart. Ein besserer Weg:

• Kleiner Standard-Seed für den Alltag
• Optionaler Performance-Seed für gezielte Tests
• Gezielte Kantenfälle statt „Masse“

Kurzer Ablauf für ein robustes Setup

• Basisdaten (Rollen, Statuslisten) als eigenen Seed-Baustein anlegen.
• Beispieldaten pro Feature-Bereich modular halten (Users, Produkte, Orders).
• Deterministische Erzeugung sicherstellen (fester Zufalls-Seed, feste Mengen).
• Für CI ein minimales Dataset definieren, das alle Tests unterstützt.
• Reset-Workflow dokumentieren: „DB leeren → migrieren → seed“.
• Kantenfälle bewusst hinzufügen (leer, extrem, Sonderzeichen, fehlende Beziehungen).

Entscheidungshilfe: Welcher Seed-Ansatz passt zum Projekt?

• Wenn lokale Entwickler oft „von vorn“ starten müssen:
  • Reset-Ansatz + schneller Standard-Seed
• Wenn Basisdaten dauerhaft vorhanden sein müssen (z. B. Rollen):
  • Idempotente Seeds für Basisdaten
• Wenn CI-Tests gelegentlich flackern:
  • Deterministische Generatoren + minimaler CI-Seed + Reset pro Lauf
• Wenn Staging für Demos genutzt wird:
  • Separater „Demo-Seed“ mit kuratierten Beispielen

Kurze Praxis-Tabelle: Seed-Daten sinnvoll aufteilen

Ein Seed-Setup ist dann gut, wenn es im Team kaum Aufmerksamkeit braucht: neue Kolleg:innen können sofort loslegen, CI läuft stabil und Bugs lassen sich reproduzieren. Das Ziel sind nicht perfekte Daten, sondern verlässliche Arbeitsbedingungen.