A fixture in Playwright is like a reusable setup helper that provides something your tests need — for example, a browser, a page, a logged-in user, or an API client.

Think of fixtures as:

“A small factory that prepares something before a test runs, gives it to the test, and then cleans it up after the test finishes.”

🔹 Why are fixtures important?

In real testing, you often need:

• To open a browser before running tests

• To log in before accessing secure pages

• To connect to an API before calling endpoints

• To clean up after tests (e.g., close the browser or clear data)

Doing all that setup and teardown manually in every test would be:

• Repetitive 🌀

• Time-consuming ⏳

• Error-prone ❌

Fixtures solve that by automatically handling this setup and cleanup logic — so your tests stay clean and focused on behavior, not setup.

🏗️ How Fixtures Work (Conceptually)

Imagine you’re testing a web app:

1. Before your test starts, Playwright creates the environment using fixtures.

2. The test uses those fixtures (like a page or a browser).

3. When the test ends, Playwright cleans up automatically.

So, a fixture has three stages:

1. Setup – Prepare what’s needed (e.g., open browser, connect to DB).

2. Use – Provide it to the test (the test can use this object).

3. Teardown – Close or destroy it when done.

⚙️ Built-in Fixtures

Playwright comes with some built-in fixtures — ready to use.

{ page }

Playwright automatically gives you a ready-to-use browser tab — no need to launch or close it yourself.

🧠 Why use Custom Fixtures?

Built-in fixtures are great, but sometimes you need something specific to your project.

For example:

• A logged-in user (so every test starts already authenticated)

• A database connection (so you can insert or check data)

• A mocked API (so tests don’t hit real servers)

You can create your own fixture to handle those setups.
In simple words, a custom fixture means:

“Before tests start, I’ll prepare something useful — like a login — and give it to all tests that need it.

💬 Example (Theory-based)

Let’s say you’re testing an e-commerce app.

Without fixtures:

1. Each test has to log in manually (fill email, password, click login).

2. That means repeating login code in every single test.

With fixtures:

• You create a login fixture that logs in once, then shares the logged-in session with tests.

• Every test starts already logged in.

So your tests become simpler:

Instead of saying “open login page → fill username → fill password → click login”
you can now just say “use logged-in user”.

That’s the power of fixtures.

🕓 Fixture Scopes: Test vs Worker

Fixtures can have different lifetimes depending on how you want them to behave.

1. Test-Scoped Fixture

• Runs once per test.

• Example: Each test gets a fresh browser page.

• Useful when tests need isolation (nothing shared).

🧠 Analogy:

Like giving each student their own notebook.

2. Worker-Scoped Fixture

• Runs once per worker (thread) and is shared among tests.

• Example: A database connection that all tests use.

• Saves time since it’s created only once.

🧠 Analogy:

Like one shared projector for the whole classroom.

🌐 Real-Life Theoretical Scenarios

Let’s make this more practical with simple mental images.

✅ Scenario 1: Testing Login Page

You have 10 tests that all require a logged-in user.

• Without fixtures → Each test logs in separately.

• With a fixture → One fixture handles login, and all tests reuse it.

Result: Less code repetition, faster tests, fewer login errors.

✅ Scenario 2: Testing API Calls

You want to test an API that needs an authentication token.

• The fixture runs before tests, fetches the token from the API, and stores it.

• All tests that need to make API requests can reuse that token.

Result: Clean tests that don’t need to worry about token management.

✅ Scenario 3: Setting Up Test Data

Imagine you need some data inserted in the database before running UI tests.

• A fixture connects to the database, inserts dummy data, then tears down after tests finish.

Result: Every test starts in a predictable state.

🧱 Fixture Lifecycle (Simplified)

🏁 Why Fixtures Matter (In Real Projects)

Fixtures make large automation projects:
✅ Easier to maintain
✅ Faster to run
✅ More reliable
✅ Cleaner to read

They promote modularity — meaning each setup piece can be reused across tests without rewriting.

🎓 In Summary

💡 Think of Fixtures Like This:

🧰 Playwright fixtures are like pre-packed toolkits that prepare everything your test needs — open the right browser, set the right user, fetch the right data — and clean up after themselves when done.