Testdaten generieren: FK-konsistent aus SQL, Django und Prisma.

Testdaten generieren beginnt mit dem Schema, nicht mit handgetippten Werten. SeedBase liest die Tabellen, Spalten und Beziehungen aus einer von vier Quellen und baut daraus den Generierungs-Bauplan. Du musst nichts doppelt pflegen, deine Migrationen bleiben die einzige Wahrheit.

• SQL-Dump: ein CREATE TABLE-Dump aus PostgreSQL oder MySQL, direkt in den Editor eingefügt. SQL-Testdaten im Detail →
• Django: die models.py per VS-Code- oder JetBrains-Plugin pushen, ohne Copy-Paste. Django-Testdaten im Detail →
• Prisma: das schema.prisma hochladen, Relationen werden mitgelesen.
• Live-Datenbank: eine lesende Verbindung angeben, SeedBase liest die echte Struktur per Introspektion aus.

Per CLI lässt sich derselbe Import skripten. Erst Schema einlesen, dann generieren:

# Python-CLI, Schema aus einem SQL-Dump anlegen
pip install seedbase
seedbase login
seedbase project create shop --from-sql schema.sql

Auch über das Node-SDK oder den MCP-Server für KI-Assistenten ist der Import erreichbar. Die ganze Bandbreite steht in der Doku.

Der Kern beim Testdaten generieren ist die Fremdschlüssel-Konsistenz: Jeder Kind-Datensatz zeigt auf eine existierende Eltern-Zeile, über das ganze Schema hinweg, auch bei Selbstreferenzen (parent_id) und 1:1-Beziehungen. SeedBase fügt die Tabellen in topologischer Reihenfolge ein, sodass keine Verletzung der referenziellen Integrität entsteht. Getestet an einem echten Django-Projekt mit 20 Apps und 226 Tabellen, also genau dem Fall, für den FK-Konsistenz über hunderte Tabellen zählt.

Mit dem Node-SDK @seedbase/client generierst du eine SQL-Datei und lädst sie in deine Datenbank:

// generate.mjs, FK-konsistente Daten als SQL exportieren
import { SeedbaseClient } from "@seedbase/client";
import { writeFile } from "node:fs/promises";

const client = new SeedbaseClient({ token: process.env.SEEDBASE_TOKEN });
const gen = await client.generate(process.env.SEEDBASE_PROJECT, {
  seed: 42,
  wait: true,
});
// SQL, CSV oder JSON, hier INSERTs in FK-sicherer Reihenfolge
await writeFile("seed.sql", await client.download(gen.id, { format: "sql" }));

Wer die Zeilen lieber im Speicher als Fixture braucht, bekommt sie tabellenweise und schon in Fremdschlüssel-sicherer Reihenfolge zurück:

const rows = await client.seededRows(projectId, { seed: 42, rows: 100 });
// { kunden: [...], bestellungen: [...], positionen: [...] }

Statt SQL kannst du auch CSV oder JSON exportieren oder die Daten per direktem DB-Push gleich in Postgres oder MySQL schreiben.

Damit Snapshot-Tests und CI-Läufe stabil bleiben, ist die Generierung deterministisch: Derselbe Seed plus dasselbe Schema ergeben bei jedem Lauf exakt dieselben Zeilen. Ein gepinntes Referenzdatum macht zusätzlich die Zeitstempel reproduzierbar. Ein fehlschlagender Test lässt sich lokal mit demselben seed: 42 exakt nachstellen.

# .github/workflows/test.yml
- run: node generate.mjs
- run: psql "$DATABASE_URL" -f seed.sql
- run: pytest

Die Generierungs-Konfiguration lässt sich als JSON exportieren und neben den Migrationen versionieren (config-as-code). Für Python gibt es zusätzlich ein pytest-Plugin, dazu CLI und SDKs für Node und PHP, sodass die Testdaten-Generierung in jede Pipeline passt.

Vollsynthetische Testdaten sind der sichere Weg, weil hinter ihnen keine echten Personen stehen. Manchmal müssen die Daten aber näher am Original liegen, etwa für einen reproduzierten Fehlerfall. Dann kopierst du keine Produktionsdatenbank, sondern lässt SeedBase die personenbezogenen Felder erkennen und formatwahrend maskieren: Aus einer echten E-Mail wird eine plausibel aussehende, aus einer IBAN eine gültig strukturierte, und gleiche Werte werden überall gleich ersetzt, sodass Joins konsistent bleiben.

So gehen weder Format noch referenzielle Beziehungen verloren, und es liegen keine echten E-Mails, IBANs oder Adressen mehr auf Dev-Rechnern oder in CI-Volumes. Details und der DSGVO-Kontext stehen auf der Seite zur DSGVO-konformen Anonymisierung.