A fixture in Playwright is a piece of environment or data that is prepared in advance for a test to use. It is the core concept behind Playwright's built-in dependency injection system, allowing you to isolate and establish a clean, predictable state for every single test case.Instead of writing repetitive code to open a browser, create a page, or configure headers inside traditional beforeEach and afterEach hooks, you simply ask for what your test needs by passing it as an argument.How Fixtures WorkFixtures encapsulate both the setup and teardown logic within a single function using the await use() statement.Code written before await use() acts as the setup phase.The await use() function hands control over to the test itself (and passes any necessary values).Code written after await use() automatically acts as the cleanup/teardown phase once the test finishes.
Example of a Built-In FixtureWhen you write a standard Playwright test, you are already using fixtures, most notably the { page } fixture:javascriptimport { test, expect } from '@playwright/test';
// { page } is a built-in fixture automatically injected into the test
test('basic test', async ({ page }) => {
await page.goto('https://playwright.dev/');
await expect(page).toHaveTitle(/Playwright/);
});
Behind the scenes, Playwright automatically launches the browser, creates a unique browser context (like an incognito window), and passes a new page tab into your test block without you needing to manage the browser lifecycle manually.Primary Built-In FixturesPlaywright offers several pre-configured fixtures out of the box:page: An isolated browser tab instance for the specific test run.context: An isolated browser context (session) that handles unique cookies and storage states.browser: The actual browser instance shared across multiple tests in a single worker process.request: A pre-configured API request context instance to handle backend API testing calls.Why Use Fixtures Over Hooks (beforeEach / afterEach)?The Playwright documentation recommends fixtures over traditional hooks because they provide distinct architectural advantages:🏃 Lazy and On-Demand: Fixtures only execute if a specific test explicitly requests them in its arguments. Traditional hooks run before every test regardless of whether the test needs that setup.🧩 Composable: Fixtures can depend on other fixtures. For instance, a custom authenticatedPage fixture can automatically consume and build upon the built-in page fixture.🔀 Scoped Flexibility: They can be configured as test-scoped (recreated for every test case for absolute isolation) or worker-scoped (created once and shared across multiple parallel tests for expensive tasks like setting up a database connection).🛠️ Customizable: You can easily build custom fixtures using test.extend() to encapsulate Page Object Models (POM), log-in sessions, or global mock states into single, reusable arguments.Would you like to see a practical code example of how to create a custom fixture (like an authenticated session or a Page Object Model fixture), or are you trying to migrate existing beforeEach hooks to a fixture-based setup?
No comments:
Post a Comment