Lazy fixtures in PyTest - Test Execution Trace

Test Overview

This test uses a lazy fixture to provide test data only when needed. It verifies that the lazy fixture correctly supplies the expected value during test execution.

Test Code - pytest

PyTest

import pytest

@pytest.fixture
def data():
    print("Setup data fixture")
    return 42

@pytest.mark.parametrize('lazy_fixture', [pytest.lazy_fixture('data')])
def test_lazy_fixture(lazy_fixture):
    assert lazy_fixture == 42

Execution Trace - 4 Steps

Step	Action	System State	Assertion	Result
1	Test runner starts and collects tests	pytest collects test_lazy_fixture with lazy_fixture parameter	—	PASS
2	pytest invokes the 'data' fixture lazily when test_lazy_fixture runs	Fixture 'data' setup prints 'Setup data fixture' and returns 42	—	PASS
3	test_lazy_fixture receives lazy_fixture value 42 and runs assertion	Inside test, lazy_fixture == 42	assert lazy_fixture == 42	PASS
4	Test completes successfully	Test passed with no errors	—	PASS

Failure Scenario

Failing Condition: The lazy fixture 'data' is not found or returns wrong value

Execution Trace Quiz - 3 Questions

What triggers the 'data' fixture to run in this test?

A At the start of the test session

B Before pytest collects tests

C When the test function uses lazy_fixture parameter

D When pytest starts the test runner

Key Result

Using lazy fixtures allows tests to request fixture data only when needed, improving test flexibility and avoiding unnecessary setup.

Practice

1. What is the main benefit of using lazy_fixture in pytest tests?

easy

A. It automatically retries failed tests using the fixture.

B. It runs all fixtures before any test starts, ensuring setup order.

C. It delays fixture setup until the test actually needs it, improving speed.

D. It converts fixtures into global variables accessible everywhere.

Solution

1. Step 1: Understand lazy_fixture purpose

   The lazy_fixture delays the setup of a fixture until the test that uses it actually runs, avoiding unnecessary setup.

2. Step 2: Compare options to this behavior

   Only It delays fixture setup until the test actually needs it, improving speed. correctly describes this benefit. Other options describe unrelated behaviors.

3. Final Answer:

   It delays fixture setup until the test actually needs it, improving speed. -> Option C

4. Quick Check:

   lazy_fixture delays setup = A [OK]

Hint: Lazy fixtures delay setup until needed, saving time [OK]

Common Mistakes:

• Thinking lazy_fixture runs all fixtures upfront
• Confusing lazy_fixture with test retries
• Assuming lazy_fixture makes fixtures global

2. Which of the following is the correct way to use lazy_fixture inside pytest.mark.parametrize?

easy

A. pytest.mark.parametrize('data', lazy_fixture('my_fixture'))

B. pytest.mark.parametrize('data', lazy_fixture(['my_fixture']))

C. pytest.mark.parametrize('data', ['lazy_fixture(my_fixture)'])

D. pytest.mark.parametrize('data', [lazy_fixture('my_fixture')])

Solution

1. Step 1: Recall correct syntax for lazy_fixture usage

   The lazy_fixture function must be called inside the list of parameters passed to pytest.mark.parametrize, like [lazy_fixture('fixture_name')].

2. Step 2: Check each option's syntax

   pytest.mark.parametrize('data', [lazy_fixture('my_fixture')]) correctly wraps lazy_fixture('my_fixture') inside a list. Options A and D misuse the function call or argument types. pytest.mark.parametrize('data', ['lazy_fixture(my_fixture)']) treats it as a string, which is incorrect.

3. Final Answer:

   pytest.mark.parametrize('data', [lazy_fixture('my_fixture')]) -> Option D

4. Quick Check:

   lazy_fixture inside list = B [OK]

Hint: Use lazy_fixture inside a list in parametrize [OK]

Common Mistakes:

• Passing lazy_fixture call directly without list
• Using string quotes around lazy_fixture call
• Passing list inside lazy_fixture instead of outside

3. Given the code below, what will be the output when running the test?

import pytest
from pytest_lazyfixture import lazy_fixture

@pytest.fixture
def number():
    print('Setup number')
    return 42

@pytest.mark.parametrize('value', [lazy_fixture('number')])
def test_value(value):
    print(f'Test got {value}')
    assert value == 42

medium

A. Setup number\nTest got 42

B. Test got 42\nSetup number

C. Setup number only

D. No output, test skipped

Solution

1. Step 1: Understand lazy_fixture execution timing

   The fixture number is only set up when the test runs because of lazy_fixture. So 'Setup number' prints before the test body.

2. Step 2: Trace test execution output

   First, 'Setup number' prints from fixture setup, then 'Test got 42' prints from the test function. The assertion passes.

3. Final Answer:

   Setup number Test got 42 -> Option A

4. Quick Check:

   Fixture setup before test print = A [OK]

Hint: Fixture prints before test body when lazy_fixture used [OK]

Common Mistakes:

• Assuming test prints before fixture setup
• Thinking fixture runs before parametrize
• Expecting no output due to lazy_fixture

4. Identify the error in the following pytest code using lazy_fixture:

import pytest
from pytest_lazyfixture import lazy_fixture

@pytest.fixture
def data():
    return [1, 2, 3]

@pytest.mark.parametrize('input', lazy_fixture('data'))
def test_sum(input):
    assert sum(input) == 6

medium

A. The test function must not use parameter named 'input'.

B. lazy_fixture must be inside a list in parametrize, not passed directly.

C. Fixture 'data' must return a single integer, not a list.

D. lazy_fixture cannot be used with parametrize.

Solution

1. Step 1: Check lazy_fixture usage in parametrize

   The lazy_fixture call must be inside a list when passed to pytest.mark.parametrize. Here it is passed directly, which is incorrect syntax.

2. Step 2: Validate other code parts

   The fixture returns a list correctly, parameter name 'input' is allowed, and lazy_fixture is designed for parametrize usage.

3. Final Answer:

   lazy_fixture must be inside a list in parametrize, not passed directly. -> Option B

4. Quick Check:

   lazy_fixture inside list required = C [OK]

Hint: Wrap lazy_fixture call in a list for parametrize [OK]

Common Mistakes:

• Passing lazy_fixture call directly without list
• Misunderstanding fixture return types
• Thinking parameter names are restricted

5. You want to test a function with two different fixtures, but only one fixture should be set up per test run to save time. How can you use lazy_fixture with pytest.mark.parametrize to achieve this?

hard

A. Use pytest.mark.parametrize('arg', [lazy_fixture('fix1'), lazy_fixture('fix2')]) so only the needed fixture runs per test.

B. Call both fixtures inside the test and use lazy_fixture to delay both setups.

C. Use pytest.mark.parametrize with a list of fixture names as strings, then call them inside the test.

D. Set both fixtures as autouse=True to run only one at a time.

Solution

1. Step 1: Understand lazy_fixture with parametrize

   Using lazy_fixture inside the list passed to pytest.mark.parametrize allows pytest to run only the fixture needed for each test case.

2. Step 2: Evaluate options for efficiency

   Use pytest.mark.parametrize('arg', [lazy_fixture('fix1'), lazy_fixture('fix2')]) so only the needed fixture runs per test. correctly uses lazy_fixture in the parametrize list, so only one fixture runs per test. Call both fixtures inside the test and use lazy_fixture to delay both setups. runs both fixtures regardless. Use pytest.mark.parametrize with a list of fixture names as strings, then call them inside the test. uses strings incorrectly. Set both fixtures as autouse=True to run only one at a time. misuses autouse and does not control fixture setup per test.

3. Final Answer:

   Use pytest.mark.parametrize('arg', [lazy_fixture('fix1'), lazy_fixture('fix2')]) so only the needed fixture runs per test. -> Option A

4. Quick Check:

   lazy_fixture in parametrize list runs one fixture per test = D [OK]

Hint: Parametrize with lazy_fixture list to run one fixture per test [OK]

Common Mistakes:

• Calling both fixtures inside test causing both setups
• Passing fixture names as strings without lazy_fixture
• Misusing autouse to control fixture runs