Fixture composition in PyTest - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of composed pytest fixtures

What is the output when running this pytest test with the given fixtures?

PyTest

import pytest

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

@pytest.fixture
def extended_data(base_data):
    return base_data + [4, 5]

def test_sum(extended_data):
    assert sum(extended_data) == 15
    print(sum(extended_data))

A TypeError

B 15

C 14

D AssertionError

💡 Hint

Think about how fixtures can use other fixtures as input and how the list is extended.

The base_data fixture returns [1, 2, 3]. The extended_data fixture adds [4, 5] to it, resulting in [1, 2, 3, 4, 5]. The sum is 15, so the assertion passes and 15 is printed.

❓ assertion

intermediate

Correct assertion for nested fixture output

Given these fixtures, which assertion correctly verifies the final output in the test?

PyTest

import pytest

@pytest.fixture
def user():
    return {'name': 'Alice', 'age': 30}

@pytest.fixture
def user_with_email(user):
    user['email'] = '[e-mail]'
    return user

def test_user_email(user_with_email):
    # Which assertion is correct here?

A assert user_with_email['email'] == '[e-mail]'

B assert user_with_email['age'] == 25

C assert 'email' not in user_with_email

D assert user_with_email['email'] == '[e-mail]' and user_with_email['age'] == 30

💡 Hint

Check how the email is added in the second fixture and the age remains unchanged.

The user_with_email fixture adds the email key with value '[e-mail]' to the user dictionary. The age remains 30. So the assertion in option D correctly checks both.

🔧 Debug

advanced

Identify the cause of fixture reuse error

Why does this pytest test raise an error about fixture scope when running?

PyTest

import pytest

@pytest.fixture(scope='function')
def db_connection():
    return 'db_conn'

@pytest.fixture(scope='module')
def user_session(db_connection):
    return f'session using {db_connection}'

def test_session(user_session):
    assert 'session' in user_session

A Fixture 'user_session' has a wider scope than 'db_connection', causing a scope mismatch error.

B The 'db_connection' fixture is missing a return statement.

C The test function is missing a parameter for 'db_connection'.

D The 'user_session' fixture should not depend on another fixture.

💡 Hint

Think about pytest fixture scopes and their allowed dependencies.

In pytest, a fixture with a wider scope (module) cannot depend on a fixture with a narrower scope (function) because the narrower scope fixture might be destroyed before the wider scope fixture finishes. Here, 'user_session' (module scope) depends on 'db_connection' (function scope), causing a scope mismatch error.

❓ framework

advanced

Best practice for fixture composition in pytest

Which option correctly describes a best practice when composing fixtures in pytest?

A Fixtures should never return mutable objects to avoid side effects.

B Avoid using fixtures as parameters to other fixtures; use global variables instead.

C Always keep fixture scopes compatible; a fixture should not depend on another fixture with a narrower scope.

D Use fixtures only for setup, never for providing test data.

💡 Hint

Think about how pytest manages fixture lifetimes and dependencies.

In pytest, a fixture with a wider scope cannot depend on a fixture with a narrower scope because the narrower scope fixture might be destroyed before the wider scope fixture finishes. So keeping scopes compatible is a best practice.

🧠 Conceptual

expert

Understanding fixture teardown order in composed fixtures

Given these fixtures, in what order will the teardown code run after the test completes?

PyTest

import pytest

@pytest.fixture
def resource_a():
    print('Setup A')
    yield 'A'
    print('Teardown A')

@pytest.fixture
def resource_b(resource_a):
    print('Setup B')
    yield 'B'
    print('Teardown B')

def test_resources(resource_b):
    print('Test running')

A 1,2,3,4,5

B 2,1,3,4,5

C 1,2,3,5,4

D 2,1,3,5,4

💡 Hint

Fixtures teardown in reverse order of setup, respecting dependencies.

resource_a is setup first, then resource_b. The test runs. Then teardown happens in reverse: resource_b teardown first, then resource_a.