Der Test aus Kapitel 43 (findOneBy(['email' => 'anna@example.com'])) setzt voraus, dass DIESER Nutzer existiert – zum Abschluss von Block 7 richten wir eine SAUBERE, ISOLIERTE Test-Datenbank mit reproduzierbaren Testdaten ein.

Warum eine EIGENE Datenbank nur für Tests?

Die Test-Umgebung konfigurieren

DATABASE_URL="postgresql://symfony:symfony@127.0.0.1:5432/aufgaben_manager_test?serverVersion=16&charset=utf8"

GENAU das Muster aus Kapitel 4: .env.test überschreibt DATABASE_URL NUR für die test-Umgebung – WebTestCase aus Kapitel 43 bootet die Anwendung automatisch mit APP_ENV=test, verwendet also AUTOMATISCH diese separate Datenbank.

Die Test-Datenbank anlegen und migrieren

php bin/console doctrine:database:create --env=test
php bin/console doctrine:migrations:migrate --env=test --no-interaction

--env=test überschreibt die Standard-Umgebung EXPLIZIT – GENAU dieselben Migrationen aus Kapitel 20, angewendet auf die SEPARATE Test-Datenbank.

Die Fixtures aus Kapitel 25 für Tests wiederverwenden

php bin/console doctrine:fixtures:load --env=test --no-interaction

GENAU dieselben Fixture-Klassen aus Block 4 – KEINE separaten Test-Fixtures nötig, solange die Kern-Fixtures (wie der Nutzer "Anna Schmidt" mit fester anna@example.com-Adresse aus Kapitel 25) für Tests referenzierbar bleiben.

Die Datenbank vor JEDEM Testlauf zurücksetzen

Damit Tests UNABHÄNGIG voneinander und REPRODUZIERBAR bleiben, sollte die Test-Datenbank vor JEDEM vollständigen Testlauf neu aufgesetzt werden – ein einfaches Skript dafür:

#!/bin/bash
set -e

php bin/console doctrine:database:drop --env=test --force --if-exists
php bin/console doctrine:database:create --env=test
php bin/console doctrine:migrations:migrate --env=test --no-interaction
php bin/console doctrine:fixtures:load --env=test --no-interaction

chmod +x bin/reset-test-db.sh
./bin/reset-test-db.sh && php bin/phpunit

Eine schnellere Alternative: Transaktions-Rollback pro Test

Das komplette Neu-Aufsetzen der Datenbank ist bei GROSSEN Testsuiten langsam – ein fortgeschrittenerer Ansatz (z. B. mit dem Paket dama/doctrine-test-bundle) startet vor JEDEM einzelnen Test eine Datenbank-TRANSAKTION und macht sie am Testende per ROLLBACK rückgängig – DEUTLICH schneller als jedes Mal die komplette Datenbank neu aufzubauen, aber ein eigenes, fortgeschritteneres Setup, das über den Rahmen dieser Einführung hinausgeht.

Anna verlässlich in Tests referenzieren

// In Tests, statt der E-Mail-Adresse als 'magic string':
use App\DataFixtures\UserFixtures;

// Besser: Konstanten aus den Fixture-Klassen (Kapitel 25) direkt referenzieren,
// statt die E-Mail-Adresse an mehreren Stellen zu wiederholen.
// (Erfordert eine leichte Erweiterung von UserFixtures um eine öffentliche E-Mail-Konstante.)