Seed Daten als Teamstandard: eine Welt für Entwickler, Tests und KI Agenten

Seed Daten sind in vielen Teams Privatsache. Jeder hat seinen eigenen Datenstand, seine eigenen Testaccounts und seine Lieblingsbestellung zum Ausprobieren. Das hält, bis ein Bug nur auf einem einzigen Rechner auftaucht. Als Teamstandard sieht es anders aus. Ein Seed Skript liegt im Repository, der Seed-Wert ist fest, und Entwickler, Tests und KI Agenten arbeiten auf exakt derselben Welt.

Teil 2 der Serie zu Seed Daten im Team. Teil 1: Team Onboarding mit Seed Daten. Teil 3: Staging ohne Produktionsdaten.

Das Ende von „bei mir geht’s“

Ein Ticket kommt rein: Die Rechnung bricht bei Kunden mit langem Doppelnamen. Die erste Entwicklerin kann es nicht nachstellen, weil ihre Datenbank keinen solchen Kunden kennt. Der zweite hat einen, aber mit anderer ID. Eine Stunde später diskutieren drei Leute über drei verschiedene Datenstände.

Mit einem gemeinsamen Seed läuft das Gespräch anders. Kunde 1 ist auf jedem Rechner die Annegret Müller-Lüdenscheidt-Großkopf. Der Bugreport nennt die ID, und alle sehen sofort dasselbe. Auch der Neue, der erst seit Montag im Team ist.

Ein Seed-Wert für drei Sprachen

Wir nutzen Faker in allen Projekten, egal ob PHP, JavaScript oder Python. Das Prinzip ist überall gleich: Seed setzen, Locale wählen, Daten erzeugen. Damit sich niemand merken muss, wie es in welcher Sprache heißt, legen wir eine Teamregel fest. Der Seed-Wert ist überall derselbe.

Sprache	Seed setzen	Deutsche Locale
PHP mit FakerPHP	$faker->seed(2026)	de_DE
JavaScript und TypeScript	faker.seed(2026)	de
Python	Faker.seed(2026)	de_DE

Die Details stehen in der Dokumentation von FakerPHP und von Faker für Python. Den Überblick über alle drei Varianten findet ihr auf unserer Seite zu Faker Testdaten.

Fixtures als Quelle der Wahrheit

Masse allein reicht nicht. Neben hunderten Zufallsdatensätzen legen wir bewusst Sonderfälle mit festen Werten an. Der gesperrte Account, der Kunde mit sehr langem Namen, die Bestellung ohne Lieferadresse. Tests und Bugreports können diese Fälle gezielt ansprechen. In Symfony sieht das so aus:

use App\Entity\Customer;
use Doctrine\Bundle\FixturesBundle\Fixture;
use Doctrine\Persistence\ObjectManager;
use Faker\Factory;

final class CustomerFixtures extends Fixture
{
    public function load(ObjectManager $manager): void
    {
        $faker = Factory::create('de_DE');
        $faker->seed(2026);

        // Fester Sonderfall für Tests und Bugreports
        $longName = new Customer();
        $longName->setName('Annegret Müller-Lüdenscheidt-Großkopf');
        $longName->setEmail('sonderfall@example.com');
        $manager->persist($longName);

        foreach (range(1, 500) as $i) {
            $customer = new Customer();
            $customer->setName($faker->name());
            $customer->setEmail($faker->unique()->safeEmail());
            $manager->persist($customer);
        }

        $manager->flush();
    }
}

Ein Detail mit Wirkung: safeEmail() erzeugt nur Adressen auf reservierten Beispieldomains. Selbst wenn eine Mail versehentlich rausgeht, landet sie bei keiner echten Person.

Tests laufen auf denselben Daten

Ein Seed, der nur für die lokale Entwicklung gilt, ist ein halber Standard. Bei uns nutzen PHPUnit, pytest und Cypress dieselben Seeds wie die Entwicklung. In Cypress lädt ein Task die Daten vor jeder Spec frisch:

// cypress.config.ts
import { defineConfig } from 'cypress';
import { execSync } from 'node:child_process';

export default defineConfig({
  e2e: {
    setupNodeEvents(on) {
      on('task', {
        'db:seed'() {
          execSync('make reset-seed', { stdio: 'inherit' });
          return null;
        },
      });
    },
  },
});

// in der Spec
before(() => {
  cy.task('db:seed');
});

Wie cy.task im Detail funktioniert, beschreibt die Cypress Dokumentation. Mehr zu Fixtures und Seeding im E2E Kontext steht in unserem Glossar unter Testdaten in Cypress. In Python reicht für pytest eine Fixture faker_seed in der conftest.py, die denselben Wert zurückgibt.

KI Agenten bekommen dieselben Regeln

Ein Coding Agent arbeitet nur so gut wie die Umgebung, die er sieht. Deshalb steht der Seed in den Agentenregeln. OpenCode liest die AGENTS.md im Repository bei jedem Start. Ein paar Zeilen genügen:

## Testdaten
- Lokal und auf Staging gibt es nur Seed Daten. Nie mit echten Daten arbeiten.
- Vor größeren Änderungen: make reset-seed
- Neue Entitäten bekommen im selben Commit einen Seed Eintrag.
- Der Seed-Wert bleibt 2026. Nicht ändern.
- Sonderfälle aus Bugreports werden als feste Seed Datensätze ergänzt.

Damit gilt für den Agenten dasselbe wie für den neuen Kollegen. Er findet eine gefüllte Datenbank, kennt die Sonderfälle und hält sich an dieselben Konventionen. Wie man solche Regeldateien sauber aufbaut, steht auf unserer Seite zu rules.md und AGENTS.md.

Seeds gehören ins Code Review

Ein Standard lebt nur, wenn er geprüft wird. Vier Regeln machen Seeds zum festen Teil jedes Merge Requests:

• Neue Entität ohne Seed ist nicht fertig. Migration und Fixture kommen im selben Merge Request.
• Jeder Bug wird zum Seed Fall. Der Datensatz, der den Fehler ausgelöst hat, landet als fester Sonderfall in den Fixtures. So bleibt der Fehler für immer testbar.
• Der Seed-Wert wird nicht nebenbei geändert. Sonst verschieben sich alle IDs, und jeder Bugreport im Ticketsystem zeigt ins Leere.
• Das Setup läuft in der Pipeline. Reset und Seed auf einem frischen Runner, danach die Tests.

Gerade die zweite Regel zahlt sich aus. Nach ein paar Monaten bilden die Fixtures genau die Fälle ab, an denen euer System schon einmal gescheitert ist. Neue Teammitglieder lernen so die Stolperfallen kennen, bevor sie selbst hineinlaufen. Passende Quality Gates für KI Code laufen in derselben Pipeline.

Was Seeds nicht leisten

Seed Daten bilden keine echten Verteilungen ab. Für Lasttests mit realen Datenmengen braucht es einen anderen Weg. Und Seeds müssen gepflegt werden wie Code. Wer sie vernachlässigt, hat nach einem halben Jahr wieder ein Setup, das niemand mehr startet.

So setzen wir das bei euch um

Wir helfen Teams, Seeds vom Einzelstück zum Standard zu machen. Wir legen den gemeinsamen Seed-Wert fest, bauen Fixtures mit euren wichtigsten Sonderfällen, verbinden PHPUnit, pytest und Cypress mit denselben Daten und schreiben die Regeln in eure Agentendateien. Danach zeigen wir eurem Team, wie es das selbst weiterführt.

Wie neue Entwickler mit einem einzigen Befehl in dieses Setup einsteigen, zeigt Teil 1: Team Onboarding mit Seed Daten. Wie dieselben Daten automatisch auf Staging landen, steht in Teil 3: Staging ohne Produktionsdaten.