Magento 2 Experten — Hyvä Theme, Tailwind CSS & SEO aus einer Hand ›

Testdaten mit Doctrine Fixtures erzeugen

Testdaten mit Doctrine Fixtures erzeugen

~15 Min. Lesezeit Zuletzt aktualisiert am 8. August 2026

Bisher wurden alle Testdaten MANUELL per curl angelegt – mühsam, und bei jedem doctrine:database:drop WIEDER weg. Doctrine Fixtures lösen das REPRODUZIERBAR.

Das Fixtures-Bundle installieren

docker compose exec php composer require --dev orm-fixtures

Erstellt src/DataFixtures/ UND registriert den Konsolen-Befehl doctrine:fixtures:load – die api-platform-Distribution bringt AlICE/Foundry standardmäßig NICHT mit, das schlanke orm-fixtures reicht für unsere Zwecke völlig aus.

Eine Fixtures-Klasse anlegen

api/src/DataFixtures/AppFixtures.php
<?php

declare(strict_types=1);

namespace App\DataFixtures;

use App\Entity\Project;
use App\Entity\Tag;
use Doctrine\Bundle\FixturesBundle\Fixture;
use Doctrine\Persistence\ObjectManager;

final class AppFixtures extends Fixture
{
    public function load(ObjectManager $manager): void
    {
        $tagDringend = new Tag();
        $tagDringend->setName('Dringend');
        $manager->persist($tagDringend);

        $tagIntern = new Tag();
        $tagIntern->setName('Intern');
        $manager->persist($tagIntern);

        $projekt = new Project();
        $projekt->setName('Website-Relaunch');
        $projekt->setDescription('Kompletter Redesign des Online-Shops.');
        $manager->persist($projekt);

        $manager->flush();
    }
}

GENAU dieselbe Fixture-Basisklasse und dieselbe load()-Methode wie in der Symfony-Schulung (Kapitel 23) – ObjectManager kapselt den Doctrine EntityManager und funktioniert identisch.

Fixtures laden

docker compose exec php bin/console doctrine:fixtures:load --no-interaction

Achtung: doctrine:fixtures:load LEERT standardmäßig ALLE Tabellen VOR dem Laden (--append verhindert das) – NIEMALS ohne --append gegen eine Produktionsdatenbank ausführen.

Die Fixtures über die API prüfen

curl -k https://localhost/api/tags
{
  "@context": "/api/contexts/Tag",
  "@id": "/api/tags",
  "@type": "hydra:Collection",
  "hydra:member": [
    {"@id": "/api/tags/1", "@type": "Tag", "id": 1, "name": "Dringend"},
    {"@id": "/api/tags/2", "@type": "Tag", "id": 2, "name": "Intern"}
  ],
  "hydra:totalItems": 2
}

DIESELBEN zwei Tags aus AppFixtures, GENAU wie definiert – über den SCHREIBGESCHÜTZTEN Endpunkt aus Kapitel 12 abrufbar, obwohl POST für Tag WEITERHIN nicht existiert.

Tipp: bin/console doctrine:fixtures:load gehört ab jetzt zum STANDARD-Workflow nach jedem doctrine:database:drop/doctrine:migrations:migrate-Zyklus – so beginnt JEDER lokale Entwicklungsstand mit DENSELBEN Ausgangsdaten.