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

Testdaten und Authentifizierung in Tests

Testdaten und Authentifizierung in Tests

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

Kapitel 93s testCreateProject SCHLUG mangels Token fehl – dieses Kapitel ergänzt EINEN Testnutzer UND ein GÜLTIGES JWT, DAMIT authentifizierte Endpunkte TESTBAR werden.

Die Doctrine-Fixtures für Tests wiederverwenden

GENAU AppFixtures aus Kapitel 15 lässt sich AUCH in Tests laden – eine EIGENE, ISOLIERTE Testdatenbank (.env.test, GENAU wie in Kapitel 93 erwähnt) verhindert, dass Tests die ENTWICKLUNGSDATEN aus Kapitel 29 (45 Testprojekte) VERÄNDERN.

Einen Token für Tests erzeugen

api/tests/ProjectResourceTest.php
private function createAuthenticatedClient(): \ApiPlatform\Symfony\Bundle\Test\Client
{
    $client = static::createClient();
    $container = static::getContainer();

    $user = new \App\Entity\User();
    $user->setEmail('test@example.com');
    $user->setPassword(
        $container->get('security.user_password_hasher')->hashPassword($user, 'test1234'),
    );

    $entityManager = $container->get('doctrine')->getManager();
    $entityManager->persist($user);
    $entityManager->flush();

    $response = $client->request('POST', '/api/login', [
        'json' => ['email' => 'test@example.com', 'password' => 'test1234'],
    ]);

    $token = $response->toArray()['token'];

    $client->setDefaultOptions(['headers' => ['Authorization' => "Bearer {$token}"]]);

    return $client;
}

GENAU der Login-Flow aus Kapitel 49, jetzt PROGRAMMATISCH statt per curl DURCHLAUFEN – setDefaultOptions sorgt DAFÜR, dass ALLE nachfolgenden Requests DIESES Clients AUTOMATISCH authentifiziert sind, GENAU wie der Interceptor aus Kapitel 77 auf React-Seite.

Den Test anpassen

public function testCreateProject(): void
{
    $client = $this->createAuthenticatedClient();

    $client->request('POST', '/api/projects', [
        'json' => ['name' => 'Testprojekt'],
        'headers' => ['Content-Type' => 'application/ld+json'],
    ]);

    self::assertResponseStatusCodeSame(201);
}

Achtung: EINEN Testnutzer PRO Test NEU anzulegen ist LANGSAM (Passwort-Hashing, Kapitel 48, ist ABSICHTLICH RECHENINTENSIV) – GRÖSSERE Testsuiten lagern diese Logik in eine setUp()-Methode ODER eine WIEDERVERWENDBARE Trait aus, um sie NICHT in JEDEM Test zu wiederholen.

Den Voter testen (Kapitel 52-53)

public function testCannotDeleteOthersProject(): void
{
    $ownerClient = $this->createAuthenticatedClient();
    $response = $ownerClient->request('POST', '/api/projects', [
        'json' => ['name' => 'Fremdes Projekt'],
    ]);
    $projectIri = $response->toArray()['@id'];

    $otherClient = $this->createAuthenticatedClient();
    $otherClient->request('DELETE', $projectIri);

    self::assertResponseStatusCodeSame(403);
}

ZWEI SEPARATE authentifizierte Clients simulieren ZWEI VERSCHIEDENE Nutzer – DIESER Test verifiziert GENAU die Voter-Logik aus Kapitel 52 ($project->getOwner() === $user) AUTOMATISIERT, statt sie MANUELL mit zwei curl-Sitzungen nachzustellen.

Tipp: GENAU dieser Test WÄRE beim erstmaligen Schreiben des Voters (Kapitel 52) SOFORT FEHLGESCHLAGEN, wäre getOwner() VERGESSEN worden – AUTOMATISIERTE Tests fangen GENAU SOLCHE Regressionsfehler ab, BEVOR sie in Produktion LANDEN.