Automation

What Is Test Fixture?

A test fixture is the fixed baseline state or environment used as a starting point for test execution, including setup logic that prepares the system and teardown logic that cleans up afterward.

Start a Free Mock Interview

Free to start · 7-day trial on paid plans

In Depth

Fixtures ensure each test starts from a known, consistent state. In unit testing frameworks, fixtures are implemented through setup/teardown methods: @BeforeEach and @AfterEach in JUnit, setUp/tearDown in pytest, and beforeEach/afterEach in Jest. These methods might create test users, seed databases, initialize mock servers, or configure environment variables.

The scope of a fixture matters. Per-test fixtures (beforeEach) provide maximum isolation but are slow if they involve heavy operations like database seeding. Per-suite fixtures (beforeAll) are faster but introduce shared state that can cause test interdependencies. The best practice is to use per-test fixtures by default and only promote to per-suite when performance requires it, with careful documentation.

In end-to-end testing, fixtures often extend beyond code. Playwright fixtures provide dependency injection for browser contexts, pages, and custom helpers. Docker Compose can spin up entire service stacks as fixtures. The principle is the same regardless of scale: tests should not depend on previous tests or external state.

Why Interviewers Ask About This

Interviewers ask about fixtures to assess whether your tests are isolated and reliable. Poor fixture management is a leading cause of flaky tests and hard-to-debug failures.

Example Scenario

A test suite for an e-commerce checkout needs a logged-in user with items in the cart. The fixture creates a test user via API, adds three products to the cart, and stores the auth token. After each test, the fixture deletes the user and associated data. Tests run in isolation even when executed in parallel.

Interview Tip

Discuss fixture scope trade-offs (per-test vs. per-suite) and mention how you handle fixture failures. If a setup step fails, how do you prevent cascading false negatives?