Introduction: Why Playwright Fixtures Matter in 2026
A modern automation framework should not make every test responsible for creating its own browser objects, logging in, preparing data, initializing Page Objects, and cleaning up resources.
This is one of the problems that Playwright Fixtures solve.
Fixtures provide tests with the resources and setup they need while keeping test code clean and isolated. Playwright Test is built around fixtures, and built-in fixtures such as page, context, and browser are automatically created and cleaned up by the test runner.
For example, a simple Playwright test can use:
import { test, expect } from ‘@playwright/test’;
test(‘verify Playwright title’, async ({ page }) => {
await page.goto(‘https://playwright.dev/’);
await expect(page).toHaveTitle(/Playwright/);
});
The { page } parameter is not an ordinary function argument. It is a Playwright fixture supplied by the test runner.
As automation suites become larger, teams can create their own fixtures for:
- Page Objects
- Authentication
- API clients
- Test data
- Database setup
- Reusable application state
- Test-specific configuration
This playwright fixtures tutorial explains how fixtures work, how to create custom fixtures with TypeScript, how to combine them with Page Object Model, and how to use them in real-world CI/CD automation.
What Are Playwright Fixtures?
Playwright fixtures are reusable setup and teardown mechanisms that provide tests with the resources they need.
Instead of manually creating dependencies in every test, you define them once and let Playwright manage their lifecycle.
A simplified architecture looks like this:
Test
↓
Fixture
↓
Dependency / Setup
↓
Application
For example:
Login Test
↓
loginPage fixture
↓
LoginPage
↓
Playwright page
↓
Login UI
Playwright fixtures are isolated between tests by default. Playwright determines which fixtures a test needs and prepares only those dependencies.
Real-world use cases
Fixtures are useful for:
- Creating Page Objects
- Logging in users
- Creating test data
- Starting services
- Preparing API clients
- Configuring browser state
- Collecting debugging information
- Sharing worker-level resources
Why Use Fixtures in Playwright?
Without fixtures, a test can become repetitive:
test(‘add product’, async ({ page }) => {
const loginPage = new LoginPage(page);
const productPage = new ProductPage(page);
const cartPage = new CartPage(page);
// setup and actions…
});
With fixtures:
test(‘add product’, async ({
loginPage,
productPage,
cartPage
}) => {
});
The test becomes easier to read.
Major benefits
| Benefit | Explanation |
| Reusability | Create setup once and reuse it |
| Isolation | Test fixtures are isolated |
| Maintainability | Setup changes stay in fixture files |
| Readability | Tests focus on business scenarios |
| Type safety | TypeScript validates fixture types |
| Dependency management | Fixtures can depend on other fixtures |
| Lifecycle management | Setup and teardown are handled systematically |
| Parallel execution | Fixtures can support isolated workers |
Built-in Playwright Fixtures Overview
Playwright provides several built-in fixtures.
| Fixture | Purpose |
| page | Provides an isolated browser page |
| context | Provides an isolated browser context |
| browser | Provides the browser instance |
| browserName | Identifies the current browser |
| request | Provides an API request context |
| playwright | Provides Playwright library access |
The most commonly used built-in fixtures are page and context.
Playwright Fixture Project Setup
Create a Playwright TypeScript project:
npm init playwright@latest
Select:
TypeScript
tests
Install Playwright browsers
A basic project can look like:
playwright-fixtures/
│
├── tests/
├── pages/
├── fixtures/
├── api/
├── data/
├── utils/
├── playwright.config.ts
├── package.json
└── tsconfig.json
Install and run tests:
npm install
npx playwright test
Understanding page, context, browser, request, and Other Fixtures
1. page Fixture
The page fixture provides a Playwright Page object.
test(‘open home page’, async ({ page }) => {
await page.goto(‘https://example.com’);
});
This is the fixture you will use most often for UI automation.
2. context Fixture
A browser context provides isolated browser state such as:
- Cookies
- Local storage
- Session storage
- Permissions
Example:
test(‘verify browser context’, async ({ context }) => {
const cookies = await context.cookies();
console.log(cookies);
});
Contexts are useful when tests need to work with browser-level state.
3. browser Fixture
The browser fixture provides access to the browser instance.
For example:
test(‘create another page’, async ({ browser }) => {
const context = await browser.newContext();
const page = await context.newPage();
await page.goto(‘https://example.com’);
await context.close();
});
Use this carefully. In most normal tests, the built-in page fixture is simpler.
4. browserName
You can identify the browser being used:
test(‘browser information’, async ({ browserName }) => {
console.log(`Running on: ${browserName}`);
});
This can be useful for browser-specific debugging.
5. request
The request fixture provides an API request context.
For example:
test(‘get products’, async ({ request }) => {
const response = await request.get(‘/api/products’);
console.log(await response.json());
});
Playwright supports API testing and using APIs to prepare data for end-to-end tests.
6. playwright
The playwright fixture provides access to Playwright’s library APIs.
For example, you can create an independent API request context:
test(‘create API context’, async ({ playwright }) => {
const apiContext = await playwright.request.newContext({
baseURL: ‘https://example.com’
});
const response = await apiContext.get(‘/api/products’);
console.log(response.status());
await apiContext.dispose();
});
The playwright.request.newContext() API creates a standalone API request context.
Creating Your First Custom Playwright Fixture
The main API for creating custom fixtures is:
base.extend()
Playwright’s test.extend() creates a new test object containing your custom fixtures.
Suppose you already have a LoginPage class:
import { Page } from ‘@playwright/test’;
export class LoginPage {
constructor(private page: Page) {}
async login(username: string, password: string) {
await this.page.getByLabel(‘Username’).fill(username);
await this.page.getByLabel(‘Password’).fill(password);
await this.page.getByRole(‘button’, {
name: ‘Login’
}).click();
}
}
Now create:
fixtures/test.ts
import { test as base } from ‘@playwright/test’;
import { LoginPage } from ‘../pages/LoginPage’;
type Fixtures = {
loginPage: LoginPage;
};
export const test = base.extend<Fixtures>({
loginPage: async ({ page }, use) => {
const loginPage = new LoginPage(page);
await use(loginPage);
},
});
export { expect } from ‘@playwright/test’;
This is the core Playwright custom fixtures example.
Understanding base.extend()
This line:
export const test = base.extend<Fixtures>({
extends Playwright’s standard test object.
The type:
type Fixtures = {
loginPage: LoginPage;
};
tells TypeScript that your custom test now has a fixture named loginPage.
Then:
loginPage: async ({ page }, use) => {
means:
- Use the built-in page fixture.
- Create a LoginPage.
- Provide it to the test through use().
Understanding use()
The most important concept in a fixture is:
await use(loginPage);
Think of use() as the boundary between fixture setup and the test.
Before use():
// Setup
After use():
// Teardown
For example:
loginPage: async ({ page }, use) => {
const loginPage = new LoginPage(page);
console.log(‘Setup’);
await use(loginPage);
console.log(‘Teardown’);
}
Playwright executes setup before the test and teardown after the fixture is no longer needed. Dependencies are also ordered automatically: a dependency is set up before the fixture that uses it and torn down afterward.
Using a Custom Fixture in a Test
Now create:
tests/login.spec.ts
import { test, expect } from ‘../fixtures/test’;
test(‘user login test’, async ({ loginPage }) => {
await loginPage.login(
‘testuser’,
‘password’
);
});
The test does not need to write:
const loginPage = new LoginPage(page);
The fixture handles it.
This makes the test cleaner and easier to maintain.
Playwright Fixture Setup and Teardown
Fixtures can perform both setup and cleanup.
Example:
type Fixtures = {
testData: string;
};
export const test = base.extend<Fixtures>({
testData: async ({}, use) => {
console.log(‘Creating test data’);
const data = ‘sample-product’;
await use(data);
console.log(‘Deleting test data’);
}
});
Execution:
Create test data
↓
↓
Delete test data
This is especially useful for:
- Temporary files
- Database records
- API-created users
- Test products
- Mock services
Test-Scoped and Worker-Scoped Fixtures
Playwright supports different fixture scopes.
Test-Scoped Fixtures
Test-scoped fixtures are created for individual tests.
This is the normal approach for Page Objects.
loginPage: async ({ page }, use) => {
await use(new LoginPage(page));
}
The fixture is isolated for each test.
Worker-Scoped Fixtures
Worker-scoped fixtures are created once per worker process.
Example:
type WorkerFixtures = {
account: {
username: string;
password: string;
};
};
export const test = base.extend<{}, WorkerFixtures>({
account: [async ({}, use, workerInfo) => {
const account = {
username: `user${workerInfo.workerIndex}`,
password: ‘password’
};
await use(account);
}, { scope: ‘worker’ }]
});
Worker-scoped fixtures are useful for expensive resources that can safely be shared by tests in the same worker, such as services or worker-specific accounts.
Important difference
| Scope | Created |
| Test | For each test |
| Worker | Once per worker |
Do not make a fixture worker-scoped simply because it is convenient. Choose the scope based on isolation and resource requirements.
Automatic Playwright Fixtures
An automatic fixture runs even when a test does not explicitly request it.
Example:
export const test = base.extend<{
setupLogging: void;
}>({
setupLogging: [async ({}, use) => {
console.log(‘Starting test’);
await use();
console.log(‘Finishing test’);
}, { auto: true }]
});
Automatic fixtures are useful for cross-cutting behavior such as:
- Logging
- Environment checks
- Global diagnostics
- Automatic cleanup
- Failure artifact collection
Playwright supports automatic fixtures with { auto: true }.
Do not use automatic fixtures for everything. If a fixture is only needed by specific tests, explicit dependencies are usually clearer.
Playwright Fixtures With TypeScript
TypeScript makes custom fixtures safer.
Define:
type Fixtures = {
loginPage: LoginPage;
productPage: ProductPage;
};
Then:
export const test = base.extend<Fixtures>({
loginPage: async ({ page }, use) => {
await use(new LoginPage(page));
},
productPage: async ({ page }, use) => {
await use(new ProductPage(page));
}
});
Your IDE now understands:
test(‘product test’, async ({
loginPage,
productPage
}) => {
});
This provides autocomplete and compile-time checking.
Playwright Fixtures With Page Object Model
Fixtures and Page Objects solve different problems.
Page Object
Represents application behavior.
LoginPage
ProductPage
CartPage
CheckoutPage
Fixture
Creates and provides the Page Object.
loginPage fixture
↓
new LoginPage(page)
A practical structure is:
pages/
├── LoginPage.ts
├── ProductPage.ts
├── CartPage.ts
└── CheckoutPage.ts
fixtures/
└── test.ts
Example:
type Fixtures = {
loginPage: LoginPage;
productPage: ProductPage;
cartPage: CartPage;
};
export const test = base.extend<Fixtures>({
loginPage: async ({ page }, use) => {
await use(new LoginPage(page));
},
productPage: async ({ page }, use) => {
await use(new ProductPage(page));
},
cartPage: async ({ page }, use) => {
await use(new CartPage(page));
}
});
This is a common Playwright fixtures with Page Object Model architecture.
Authentication and Login Fixtures
Authentication is one of the most useful advanced fixture patterns.
Instead of logging in through the UI before every test, you can prepare authenticated browser state and reuse it.
Playwright supports storageState for authentication state, and its official authentication guidance shows worker-scoped authentication patterns for parallel execution.
A simple authentication fixture can look like:
type AuthFixtures = {
authenticatedPage: Page;
};
export const test = base.extend<AuthFixtures>({
authenticatedPage: async ({ page }, use) => {
await page.goto(‘/login’);
await page.getByLabel(‘Username’)
.fill(‘testuser’);
await page.getByLabel(‘Password’)
.fill(‘password’);
await page.getByRole(‘button’, {
name: ‘Login’
}).click();
await page.goto(‘/dashboard’);
await use(page);
}
});
Then:
test(‘authenticated user can view dashboard’, async ({
authenticatedPage
}) => {
await expect(
authenticatedPage.getByRole(‘heading’, {
name: ‘Dashboard’
})
).toBeVisible();
});
For larger suites, prefer reusable authentication state rather than repeatedly performing UI login when the test itself is not testing login.
Authentication state files can contain sensitive cookies and headers, so they should not be committed to source control.
API Testing With Playwright Fixtures
Fixtures work very well with API testing.
For example:
type ApiFixtures = {
productApi: {
createProduct: (
name: string
) => Promise<number>;
};
};
A simplified fixture:
export const test = base.extend<ApiFixtures>({
productApi: async ({ request }, use) => {
const api = {
createProduct: async (name: string) => {
const response = await request.post(‘/api/products’, {
data: { name }
});
const body = await response.json();
return body.id;
}
};
await use(api);
}
});
Test:
test(‘product is visible in UI’, async ({
productApi,
page
}) => {
const productId =
await productApi.createProduct(‘Laptop’);
await page.goto(`/products/${productId}`);
await expect(
page.getByText(‘Laptop’)
).toBeVisible();
});
This pattern is useful because API calls can prepare test data much faster than navigating through the UI.
Playwright’s API request contexts can also share cookies with a browser context when obtained from that context, while standalone request contexts provide isolated API state.
Test Data and Reusable Playwright Fixtures
Instead of hardcoding test data everywhere:
test(‘create customer’, async () => {
const customer = {
name: ‘John’,
email: ‘john@example.com’
};
});
create a fixture:
type DataFixtures = {
customer: {
name: string;
email: string;
};
};
export const test = base.extend<DataFixtures>({
customer: async ({}, use) => {
await use({
name: ‘Test Customer’,
email: `customer-${Date.now()}@example.com`
});
}
});
Now:
test(‘customer can register’, async ({
customer
}) => {
console.log(customer.email);
});
For more complex frameworks, test-data fixtures can create data through APIs and clean it up afterward.
Fixtures for Parallel and Cross-Browser Testing
Playwright can run tests across multiple browser projects and parallel workers.
Example:
projects: [
{
name: ‘chromium’,
use: { browserName: ‘chromium’ }
},
{
name: ‘firefox’,
use: { browserName: ‘firefox’ }
},
{
name: ‘webkit’,
use: { browserName: ‘webkit’ }
}
]
Your fixture can automatically work with the current browser.
For example:
test(‘application works’, async ({
page,
browserName
}) => {
console.log(`Browser: ${browserName}`);
await page.goto(‘/’);
});
Parallel execution makes fixture isolation important.
Avoid shared mutable state such as:
let currentOrder = {};
Instead, generate independent data for each test or worker.
For worker-specific resources, use workerInfo.workerIndex or parallelIndex to create unique resources. Playwright’s authentication documentation demonstrates this approach for worker-specific authenticated state.
Playwright Fixtures With Reporting and Debugging
Fixtures can also improve debugging.
Configure:
use: {
screenshot: ‘only-on-failure’,
video: ‘retain-on-failure’,
trace: ‘retain-on-failure’
},
reporter: [
[‘html’, { open: ‘never’ }],
[‘list’]
]
Run:
npx playwright test
Open the HTML report:
npx playwright show-report
A fixture can also attach custom diagnostic information.
For example:
import fs from ‘fs’;
export const test = base.extend<{
debugInfo: void;
}>({
debugInfo: [async ({}, use, testInfo) => {
await use();
if (testInfo.status !== testInfo.expectedStatus) {
const file = testInfo.outputPath(‘debug.txt’);
await fs.promises.writeFile(
file,
`Test failed: ${testInfo.title}`,
‘utf8’
);
testInfo.attachments.push({
name: ‘debug-info’,
contentType: ‘text/plain’,
path: file
});
}
}, { auto: true }]
});
Playwright supports attaching files to test results through testInfo.attachments, which can then be surfaced by reporters.
Playwright Fixtures in CI/CD and GitHub Actions
Fixtures do not require special CI configuration. The same test framework can execute inside GitHub Actions, Jenkins, Azure DevOps, or Docker.
Example GitHub Actions workflow:
name: Playwright Tests
on:
push:
branches: [main]
pull_request:
jobs:
test:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v6
– uses: actions/setup-node@v6
with:
node-version: lts/*
– run: npm ci
– run: npx playwright install –with-deps
– run: npx playwright test
– name: Upload report
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v5
with:
name: playwright-report
path: playwright-report/
This allows the HTML report and failure artifacts to be retained after the build.
A professional CI/CD setup can combine:
Fixtures
+
POM
+
API setup
+
Authentication
+
Parallel execution
+
+
CI artifacts
Real-World E-Commerce Playwright Fixtures Automation Project
A strong portfolio project can use the following structure:
ecommerce-playwright/
│
├── pages/
│ ├── LoginPage.ts
│ ├── HomePage.ts
│ ├── ProductPage.ts
│ ├── CartPage.ts
│ └── CheckoutPage.ts
│
├── fixtures/
│ ├── test.ts
│ ├── auth.fixture.ts
│ ├── api.fixture.ts
│ └── data.fixture.ts
│
├── api/
│ └── ProductApi.ts
│
├── data/
│ └── users.ts
│
├── tests/
│ ├── login.spec.ts
│ ├── search.spec.ts
│ ├── cart.spec.ts
│ └── checkout.spec.ts
│
├── playwright.config.ts
└── package.json
Login fixture
Provides:
loginPage
Authenticated page fixture
Provides:
authenticatedPage
Product fixture
Provides:
productPage
Cart fixture
Provides:
cartPage
Checkout fixture
Provides:
checkoutPage
API fixture
Creates test products and users.
Test-data fixture
Provides unique test data.
Example E-Commerce Test
import { test, expect } from ‘../fixtures/test’;
test(‘authenticated user can add product to cart’, async ({
productPage,
cartPage
}) => {
await productPage.searchProduct(‘Laptop’);
await productPage.addFirstProductToCart();
await cartPage.open();
await expect(
cartPage.cartItem(‘Laptop’)
).toBeVisible();
});
The test describes the business scenario rather than implementation details.
Positive scenarios
- Valid login
- Product search
- Product filtering
- Add product
- Remove product
- Successful checkout
Negative scenarios
- Invalid login
- Empty search
- Out-of-stock product
- Invalid coupon
- Missing checkout information
- Invalid payment details
Common Playwright Fixtures Errors and Solutions
1. Fixture Is Not Recognized
You may see a TypeScript error such as:
Property ‘loginPage’ does not exist
Check that the test imports:
import { test } from ‘../fixtures/test’;
rather than:
import { test } from ‘@playwright/test’;
2. Fixture Type Error
Make sure the fixture type is defined:
type Fixtures = {
loginPage: LoginPage;
};
and passed to:
base.extend<Fixtures>
3. Fixture Setup Never Runs
Fixtures are lazy by default.
If the test does not request the fixture, Playwright normally does not set it up.
If you genuinely need automatic execution:
{ auto: true }
4. Authentication Fixture Fails
Check:
- Credentials
- Base URL
- Login URL
- Authentication state
- Storage state
- Test account availability
For parallel execution, ensure different workers do not overwrite the same authentication state.
5. Fixture Timeout
Fixture setup and teardown time count toward the test timeout. For a legitimately slow fixture, Playwright allows a separate fixture timeout.
Example:
slowFixture: [async ({}, use) => {
await use(‘data’);
}, { timeout: 60000 }]
6. Parallel Test Conflicts
Avoid shared accounts or shared mutable test data unless the fixture deliberately manages that resource.
Use worker-specific resources where appropriate.
7. Teardown Failure
Remember that code after:
await use();
is teardown code.
Keep teardown reliable and make sure resources are closed or deleted appropriately.
Playwright Fixtures Best Practices
Follow these guidelines when designing a professional fixture framework.
1. Keep fixtures focused
A fixture should have one clear responsibility.
Good:
loginPage
productPage
customerData
Avoid:
everythingFixture
that creates the entire application environment for every test.
2. Prefer test scope for isolated resources
Pages and test-specific data generally belong at test scope.
3. Use worker scope for expensive shared resources
Examples:
- Test servers
- Worker-specific accounts
- Expensive initialization
4. Keep Page Objects separate
A fixture should create a Page Object, not replace it.
5. Avoid unnecessary automatic fixtures
Use { auto: true } for genuinely cross-cutting behavior.
6. Avoid global mutable state
Parallel execution makes global state especially dangerous.
7. Keep authentication secure
Never commit authentication state containing sensitive cookies or tokens.
8. Use TypeScript types
Strong types make fixture-heavy frameworks easier to maintain.
9. Use API fixtures for data setup
Creating backend data through APIs is often faster than doing the same setup through the UI.
10. Keep teardown reliable
Anything created by a fixture should be cleaned up when appropriate.
Fixtures vs Hooks vs Utilities vs Page Objects
These concepts are often confused by beginners.
| Feature | Purpose |
| Fixture | Provides reusable test dependency and lifecycle |
| Hook | Runs setup/cleanup around tests |
| Page Object | Represents application page behavior |
| Component Object | Represents reusable UI component |
| Utility | Generic reusable function |
| API Client | Encapsulates API operations |
For example:
Fixture
↓
creates LoginPage
↓
LoginPage
↓
uses locators
↓
Application
A utility should not become a replacement for every other abstraction.
Playwright Fixtures Interview Questions With Answers
1. What are Playwright fixtures?
Fixtures are reusable setup and teardown mechanisms that provide tests with required resources.
2. What is test.extend()?
test.extend() creates a new Playwright test object containing custom fixtures and/or options.
3. What does use() do?
use() provides the fixture value to the test. Code before use() is setup, while code after use() is teardown.
4. What is the difference between test-scoped and worker-scoped fixtures?
A test-scoped fixture is created for each test. A worker-scoped fixture is created once for each worker process.
5. What is an automatic fixture?
An automatic fixture uses:
{ auto: true }
and runs automatically even when a test does not explicitly request it.
6. How do fixtures work with POM?
A fixture can instantiate and provide Page Objects:
loginPage: async ({ page }, use) => {
await use(new LoginPage(page));
}
7. How do you handle authentication with fixtures?
Use authentication setup and, for larger suites, reusable storageState or worker-scoped authentication patterns.
8. Can fixtures be used for API testing?
Yes. The built-in request fixture can perform API operations, while custom API fixtures can encapsulate reusable API setup.
9. How would you design an enterprise fixture architecture?
A strong interview answer is:
“I would use test-scoped fixtures for Page Objects and isolated test data, worker-scoped fixtures for expensive worker-level resources, API fixtures for backend data preparation, authentication fixtures for reusable login state, and automatic fixtures only for cross-cutting concerns such as diagnostics.”
10. What is a common Playwright fixture anti-pattern?
One common mistake is creating a massive fixture that initializes everything for every test. Fixtures should remain focused and composable.
Playwright Fixtures Learning Roadmap for Beginners
Follow this learning sequence.
Step 1: Learn Playwright basics
Start with:
- Browser
- Context
- Page
- Locators
- Assertions
- Auto-waiting
Step 2: Learn built-in fixtures
Understand:
page
context
browser
request
browserName
playwright
Step 3: Learn test.extend()
Create a simple custom fixture.
Step 4: Learn Page Object fixtures
Create:
loginPage
productPage
cartPage
Step 5: Learn authentication
Understand:
storageState
authenticated contexts
worker authentication
Step 6: Learn API fixtures
Use APIs to create test data.
Step 7: Learn scopes
Understand:
test
worker
automatic
Step 8: Learn CI/CD
Practice:
- GitHub Actions
- Jenkins
- Azure DevOps
- Docker
Step 9: Learn reporting and debugging
Use:
- HTML reports
- Screenshots
- Videos
- Traces
- Attachments
Related subjects worth learning next include Playwright Tutorial, Playwright Tutorial Step by Step, Playwright TypeScript Tutorial, Playwright Python Tutorial, Playwright Java Tutorial, Playwright Page Object Model, Playwright Auto Waiting, Playwright Parallel Execution, Playwright Reporting, Playwright API Testing, Playwright CI/CD Pipeline, Playwright GitHub Actions, Playwright Docker Tutorial, Playwright Framework Design, and Playwright Interview Questions.
FAQs About Playwright Fixtures
What are Playwright fixtures?
Playwright fixtures are reusable setup and teardown mechanisms that provide tests with resources such as pages, browser contexts, Page Objects, authentication, and test data.
Is Playwright fixtures suitable for beginners?
Yes. Start with built-in fixtures such as page, then learn test.extend() and simple Page Object fixtures.
What are the benefits of Playwright fixtures?
The main benefits are reusable setup, isolation, lifecycle management, cleaner tests, dependency management, and better framework scalability.
How do I get started with Playwright fixtures?
Start with:
test(‘example’, async ({ page }) => {
await page.goto(‘/’);
});
Then create a custom fixture using:
base.extend()
What is a Playwright custom fixture?
A custom fixture is a user-defined dependency created with test.extend() and supplied to tests through the fixture argument.
Can Playwright fixtures work with TypeScript?
Yes. TypeScript allows you to define explicit fixture types and receive strong typing and IDE support.
Can fixtures be used with Page Object Model?
Yes. A common architecture is for fixtures to create and inject Page Object instances into tests.
Can Playwright fixtures be used for API testing?
Yes. The built-in request fixture can make API calls, and custom API fixtures can provide reusable API clients and test-data setup.
What is the difference between fixture setup and teardown?
Setup occurs before await use(…), while teardown occurs after await use(…). Playwright manages these phases according to fixture dependencies and scope.