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-fixturesErstellt 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
<?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-interactionAchtung: 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.