Testdatengenerierung mit Claude: Realistische Datensätze systematisch erzeugen

1. Warum gute Testdaten über die Aussagekraft von Tests entscheiden

Ein technisch korrekt geschriebener Test kann trotzdem wertlos sein, wenn die zugrunde liegenden Testdaten die Realität nicht abbilden. Ein Test, der einen Kunden mit genau einer Bestellung und einer Adresse prüft, sagt wenig darüber aus, ob dieselbe Logik auch für einen Kunden mit fünfzig Bestellungen, mehreren Lieferadressen und wechselnden Zahlungsarten funktioniert. Die Qualität der Testdatengenerierung bestimmt damit direkt, wie viel Vertrauen man in ein grünes Testergebnis setzen kann.

In der Praxis entstehen Testdaten oft ad hoc: ein Entwickler kopiert einen bestehenden Datensatz, ändert eine ID und nennt es einen Testfall. Das Ergebnis sind Datensätze, die zufällig funktionieren, aber weder die Bandbreite realer Daten noch deren Grenzfälle abbilden. Claude kann diesen Prozess systematisieren, indem es aus einer Datenstruktur oder einem Domänenmodell gezielt Testdatensätze mit definierter Bandbreite ableitet, statt sich auf zufällige Kopien zu verlassen.

Wichtig ist dabei die Unterscheidung zwischen zwei Zielen: Testdaten, die den Normalfall realistisch abbilden, um Business-Logik zu prüfen, und Testdaten, die gezielt Grenzfälle und ungültige Zustände abdecken, um Robustheit zu prüfen. Testdatengenerierung mit Claude deckt beide Ziele ab, wenn man dem Modell explizit mitteilt, welches der beiden gerade im Vordergrund steht.

2. Realistische vs. synthetische Testdaten

Realistische Testdaten orientieren sich an der tatsächlichen Verteilung und Struktur von Produktionsdaten: Namen, Adressen und Bestellmuster, die plausibel wirken, ohne echte Personen zu betreffen. Rein synthetische Testdaten wie "Test User 1" oder "aaa@example.com" erfüllen ihren Zweck für einfache Funktionstests, versagen aber, sobald Logik von der Datenform abhängt, etwa Sortierung nach Nachnamen mit Umlauten oder Validierung internationaler Telefonnummern.

Claude eignet sich besonders gut für die mittlere Kategorie: plausible, aber garantiert fiktive Daten, die reale Muster abbilden. Ein Prompt kann gezielt nach deutschen Nachnamen mit Umlauten, nach Adressen in mehreren europäischen Ländern mit korrektem Postleitzahlenformat oder nach realistischen Produktnamen für eine bestimmte Branche fragen. Diese Datenqualität übertrifft häufig einfache Zufallsgeneratoren, weil Claude die sprachlichen und strukturellen Muster tatsächlich versteht, statt Zeichen zufällig zu kombinieren.

3. Claude-Prompts für strukturierte Testdatensätze

Der wichtigste Grundsatz bei der Testdatengenerierung mit Claude ist, das gewünschte Ausgabeformat exakt zu spezifizieren, bevor nach Inhalt gefragt wird. Ein Prompt wie "Erzeuge zehn Kundendatensätze im JSON-Format mit den Feldern id, name, email, land und registrierungsdatum, wobei registrierungsdatum zwischen 2023 und 2026 liegen soll" liefert direkt maschinenlesbare, konsistente Daten, während eine offene Bitte um "ein paar Testkunden" zu unstrukturiertem Fließtext führt, der erst nachbearbeitet werden muss.

Ein zweiter wichtiger Baustein ist das explizite Benennen von Verteilungen: Statt zehn identisch aussehende Datensätze zu erhalten, lässt sich Claude bitten, eine realistische Streuung einzubauen, etwa achtzig Prozent Kunden aus Deutschland, Österreich und der Schweiz, den Rest aus anderen europäischen Ländern, oder eine Mischung aus Neukunden und Bestandskunden mit unterschiedlicher Bestellhistorie. Diese Streuung ist entscheidend, um Tests zu schreiben, die echte Anwendungsfälle statt eines einzigen Idealprofils abbilden.

# Claude Code CLI: generate structured, distributed test data
claude -p "Generate 20 customer records as JSON with fields:
id, name, email, country, registration_date, order_count.
Distribution: 70% Germany/Austria/Switzerland, 30% other EU.
order_count should range from 0 to 45, weighted towards low values.
Output valid JSON only, no explanation text."

4. Edge-Case-Daten und Grenzwerte generieren lassen

Neben realistischen Normaldaten braucht jede belastbare Testsuite gezielt fehlerhafte oder grenzwertige Datensätze: ein Name mit fünfzig Zeichen, eine E-Mail-Adresse mit ungewöhnlicher, aber gültiger Struktur, ein Bestelldatum in der Zukunft, ein negativer Lagerbestand durch eine fehlerhafte Synchronisation. Claude lässt sich gezielt bitten, neben dem regulären Datensatz eine zweite Reihe von Grenzfall-Datensätzen zu erzeugen, die bewusst an den Rändern des gültigen Wertebereichs liegen.

Ein bewährtes Muster ist, für jedes Feld im Datenmodell explizit nach seiner Grenze zu fragen: Was ist die maximale Feldlänge, was der kleinste und größte zulässige numerische Wert, welche Zeichen sind erlaubt, aber selten getestet, etwa Emojis in einem Namensfeld oder ein Apostroph in einer Adresse. Diese Grenzfall-Testdaten decken sich mit der klassischen Grenzwertanalyse, konzentrieren sich hier aber gezielt auf die Datenerzeugung statt auf die Testlogik selbst.

{
  "edge_case_customers": [
    {
      "name": "O'Brien-Müller",
      "email": "test+tag@sub.example.co.uk",
      "note": "apostrophe, hyphen, and umlaut in the same name"
    },
    {
      "name": "字符测试用户",
      "email": "unicode-test@example.com",
      "note": "non-Latin characters in a required name field"
    },
    {
      "name": "A",
      "email": "a@b.co",
      "note": "minimum allowed length for name and email"
    },
    {
      "name": "Very Long Customer Name That Approaches The Field Limit Of Fifty",
      "email": "long-name-boundary@example.com",
      "note": "name at exactly the 50 character database column limit"
    }
  ]
}

5. Testdaten für Datenbank-Fixtures im Magento-Kontext

In Magento-Projekten sind Testdaten häufig als PHP-Fixtures organisiert, die vor einem Integrationstest bestimmte Datenbankzustände herstellen. Claude kann aus einer Beschreibung des gewünschten Zustands, etwa "ein Kunde mit drei Bestellungen in unterschiedlichen Status und zwei gespeicherten Adressen", direkt eine passende Fixture-Klasse im erwarteten Magento-Format generieren, inklusive korrekter Verwendung der DataFixture-Attribute und Repository-Aufrufe.

Besonders wertvoll ist dieser Ansatz bei komplexen Objektgraphen mit mehreren verknüpften Entitäten, etwa Produkt, Kategorie, Preisregel und Kundengruppe gemeinsam. Das manuelle Anlegen solcher verschachtelten Fixtures ist fehleranfällig und zeitaufwendig, während Claude die Reihenfolge der Erzeugung, die korrekten Fremdschlüssel-Referenzen und die notwendigen Aufräumschritte nach dem Test in einem Zug vorschlagen kann.

<?php
declare(strict_types=1);

namespace Mironsoft\Sales\Test\Integration;

use Magento\Customer\Test\Fixture\Customer as CustomerFixture;
use Magento\Sales\Test\Fixture\Order as OrderFixture;
use Magento\TestFramework\Fixture\DataFixture;
use PHPUnit\Framework\TestCase;

/**
 * Fixture setup generated with Claude from a plain-language description:
 * "one customer with three orders in different statuses".
 */
final class CustomerOrderHistoryTest extends TestCase
{
    #[DataFixture(CustomerFixture::class, as: 'customer')]
    #[DataFixture(OrderFixture::class, ['customer_id' => '$customer.id$', 'status' => 'pending'], 'order1')]
    #[DataFixture(OrderFixture::class, ['customer_id' => '$customer.id$', 'status' => 'processing'], 'order2')]
    #[DataFixture(OrderFixture::class, ['customer_id' => '$customer.id$', 'status' => 'complete'], 'order3')]
    public function testOrderHistoryShowsAllThreeStatuses(): void
    {
        // Test body uses the fixtures created above via the DI container
        $this->assertTrue(true);
    }
}

6. Anonymisierung und DSGVO-konforme Testdaten

Ein besonders heikler Punkt bei der Testdatengenerierung ist der Umgang mit produktionsnahen Daten. Ein verbreiteter, aber riskanter Ansatz ist, einen Produktions-Datenbank-Dump für Testzwecke zu kopieren, weil er "realistisch" ist. Das verstößt in aller Regel gegen die DSGVO, sobald Testumgebungen weniger streng abgesichert sind als die Produktion, und schafft zusätzlich ein unnötiges Datenschutzrisiko. Claude kann stattdessen helfen, aus einer anonymisierten Struktur, die reale Verteilungen abbildet, ohne echte Personen zu referenzieren, gleichwertig realistische Ersatzdaten zu erzeugen.

Ein praktikables Vorgehen ist, Claude die Struktur und statistische Verteilung eines Produktionsdatensatzes zu beschreiben, ohne die eigentlichen Werte preiszugeben, etwa "zwanzig Prozent der Kunden haben mehr als drei Bestellungen, die durchschnittliche Bestellsumme liegt bei 65 Euro", und daraus einen strukturell äquivalenten, aber komplett fiktiven Datensatz generieren zu lassen. Dieses Vorgehen erfüllt den Zweck realistischer Tests, ohne dass irgendein echter Personenbezug in die Testumgebung gelangt.

# Describe production distribution to Claude without sharing real values,
# then let it generate a structurally equivalent, fully fictional dataset

production_summary = {
    "total_customers": 12000,
    "percent_with_more_than_3_orders": 20,
    "average_order_value_eur": 65,
    "top_countries": ["DE", "AT", "CH", "NL"],
}

# Prompt sent to Claude (no real customer data included):
prompt = f"""
Generate 100 fully fictional customer + order records that match
this statistical summary: {production_summary}
No real names, no real emails, no data derived from actual persons.
Output as a Python list of dicts.
"""

7. Massendaten und Performance-Testdaten generieren

Für Performance- und Lasttests werden oft zehntausende oder hunderttausende Datensätze benötigt, die weder einzeln von Hand erzeugt noch realistischerweise alle im Detail geprüft werden können. Claude eignet sich hier weniger für die direkte Erzeugung jedes einzelnen Datensatzes, sehr wohl aber für das Design des Generierungsskripts: Welche Felder sollen zufällig streuen, welche einer festen Verteilung folgen, wie werden referenzielle Beziehungen zwischen Millionen Zeilen effizient aufgelöst, ohne dass das Skript selbst zum Performance-Problem wird.

Claude kann beispielsweise ein PHP- oder SQL-Skript vorschlagen, das mit Batch-Inserts arbeitet, Indizes während der Masseneinfügung temporär deaktiviert und danach neu aufbaut, und Referenzen über vorab generierte ID-Bereiche statt über einzelne Lookups auflöst. Diese Design-Entscheidungen entscheiden bei Millionen Datensätzen über Minuten statt Stunden Laufzeit für die Testdatenvorbereitung selbst.

# Claude-assisted approach for generating 500k order rows efficiently
# 1. Disable secondary indexes before bulk insert
mysql -e "ALTER TABLE sales_order DISABLE KEYS;"

# 2. Batch insert in chunks of 5000 rows via a generated PHP script
#    (Claude designs the chunking and ID range pre-allocation logic)
php bin/generate-test-orders.php --count=500000 --batch-size=5000

# 3. Re-enable indexes and rebuild statistics after the load completes
mysql -e "ALTER TABLE sales_order ENABLE KEYS; ANALYZE TABLE sales_order;"

8. Konsistenz und Referenzintegrität sichern

Generierte Testdaten sind nur brauchbar, wenn sie in sich konsistent bleiben: Eine Bestellung muss auf einen tatsächlich existierenden Kunden verweisen, ein Rabattcode muss innerhalb seines gültigen Zeitraums liegen, eine Produktvariante muss zu einer existierenden Produktfamilie gehören. Claude kann beim Entwurf eines Generierungsskripts explizit auf diese Referenzintegrität hingewiesen werden und schlägt dann vor, IDs zuerst für alle übergeordneten Entitäten zu erzeugen, bevor abhängige Datensätze darauf verweisen, statt referenzierte IDs zu erfinden, die später ins Leere laufen.

Ein häufiger Fehler bei manuell erstellten Testdaten ist die stillschweigende Verletzung von Geschäftsregeln, etwa ein Bestelldatum, das vor dem Registrierungsdatum des Kunden liegt. Claude kann eine Liste solcher impliziten Konsistenzregeln aus dem Domänenmodell ableiten und diese als Prüfschritt in das Generierungsskript einbauen, sodass ungültige Kombinationen gar nicht erst entstehen, statt erst im Test aufzufallen.

9. Grenzen und Vergleich: manuell, Faker, Claude

Claude ersetzt keine spezialisierte Testdatenbibliothek wie Faker für reine Massenerzeugung einfacher, unstrukturierter Werte, etwa zehntausend zufällige Namen ohne besondere Anforderungen. Für diesen Fall ist eine dedizierte Bibliothek schneller und ressourcenschonender. Claudes Stärke liegt dort, wo Struktur, Domänenwissen und gezielte Grenzfälle gefragt sind, nicht in der reinen Textmenge.

Ebenso wenig ersetzt Claude die fachliche Prüfung, ob generierte Testdaten tatsächlich die relevanten Geschäftsszenarien abbilden. Ein Entwickler, der die Domäne kennt, muss weiterhin entscheiden, welche Verteilungen und Grenzfälle für das konkrete Feature wirklich wichtig sind. Die Tabelle oben zeigt, dass die Kombination aus Faker für Masse und Claude für Struktur und Grenzfälle in der Praxis oft die effizienteste Lösung ist.

10. Zusammenfassung

Testdatengenerierung mit Claude verbessert die Aussagekraft von Tests, indem sie realistische Verteilungen, gezielte Grenzfälle und referenziell konsistente Datensätze systematisch statt zufällig erzeugt. Präzise formulierte Prompts mit explizitem Ausgabeformat und gewünschter Verteilung liefern direkt verwendbare Daten für PHPUnit-Fixtures, Datenbank-Setups und Performance-Tests. Bei sensiblen Produktionsdaten hilft Claude, strukturell äquivalente, aber komplett fiktive Ersatzdaten zu erzeugen und damit DSGVO-Risiken zu vermeiden.

Die größten Gewinne entstehen aus der gezielten Kombination von Werkzeugen: Faker oder ähnliche Bibliotheken für reine Masse, Claude für Struktur, Domänenwissen und Grenzfälle. Wer diese Kombination bewusst einsetzt und Konsistenzregeln von Anfang an im Generierungsskript verankert, baut Testdaten auf, die Tests tatsächlich aussagekräftig machen, statt nur grün erscheinen zu lassen.

11. FAQ: Testdatengenerierung mit Claude