Authentication

Keep one browser test for the real login flow. For scenarios where login is only setup, start with a controlled identity so every test does not repeat the form.

Understand the bundled helper#

authenticate() writes an AUTH cookie containing a JSON identifier and context. It is a generic extension point, not an automatic bridge to Symfony Security. It works only when the application or test environment reads that cookie.

public function testAdminNavigationIsVisible(): void
{
    $this->authenticate('admin@example.com', [
        'roles' => ['ROLE_ADMIN'],
    ]);

    $page = $this->visit('/admin');

    expect($page->getByRole('navigation', ['name' => 'Admin']))->toBeVisible();
}

For a real application, create a project base test case that maps an identifier to the authentication mechanism used in the test environment. That may mean overriding a helper, setting a signed test cookie, preparing a session, or adding a request hook recognized only in test.

Use request hooks deliberately#

beforeRequest() can add a test-only header before an intercepted request reaches the kernel. The application must explicitly support that header in the test environment. Never enable the shortcut in production.

Cookies and logout#

Use setCookie(), getCookie(), clearCookie(), and clearCookies() when the test controls a cookie-based contract. logout() removes the generic AUTH cookie used by the bundle helper.

The browser context is restarted between tests, so cookies do not carry into the next test method. Database identities and server-side sessions still need normal application cleanup.

When to use core storage state#

Use Playwright storage state when the application is tested over a real server or when authentication happens outside the Symfony kernel. See Authentication and state. The Symfony-specific path is most useful when the test environment can establish identity through controlled kernel-side setup.