Shared expensive resource patterns in PyTest - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of pytest fixture with module scope

What will be the output when running this pytest code with two test functions using a module-scoped fixture?

PyTest

import pytest

@pytest.fixture(scope="module")
def resource():
    print("Setup resource")
    yield "data"
    print("Teardown resource")

def test_one(resource):
    print(f"Test one got {resource}")
    assert resource == "data"

def test_two(resource):
    print(f"Test two got {resource}")
    assert resource == "data"

A Setup resource\nTeardown resource\nTest one got data\nTest two got data

B Test one got data\nTest two got data

C Setup resource\nTest one got data\nTest two got data\nTeardown resource

D Setup resource\nTest one got data\nTeardown resource\nSetup resource\nTest two got data\nTeardown resource

💡 Hint

Module scope means the fixture runs once per module, not per test.

The fixture with scope='module' runs setup once before any tests in the module and teardown after all tests finish. So 'Setup resource' prints once, then both tests run, then 'Teardown resource' prints once.

❓ assertion

intermediate

Correct assertion for shared resource usage count

Given a shared resource fixture that counts how many times it was used, which assertion correctly verifies it was used exactly twice after two tests?

PyTest

import pytest

usage_count = 0

@pytest.fixture(scope="module")
def shared_resource():
    global usage_count
    usage_count += 1
    yield


def test_a(shared_resource):
    pass

def test_b(shared_resource):
    pass

# After tests run, which assertion is correct?

A assert usage_count == 1

B assert usage_count == 2

C assert usage_count >= 2

D assert usage_count == 0

💡 Hint

Remember the fixture scope affects how many times setup code runs.

With scope='module', the fixture setup runs once per module, so usage_count increments once even if two tests use it.

🔧 Debug

advanced

Identify the problem with fixture teardown order

This pytest code uses two fixtures: one expensive resource and one dependent on it. The teardown prints are not in expected order. What causes this?

PyTest

import pytest

@pytest.fixture(scope="module")
def expensive_resource():
    print("Setup expensive")
    yield
    print("Teardown expensive")

@pytest.fixture(scope="module")
def dependent_resource(expensive_resource):
    print("Setup dependent")
    yield
    print("Teardown dependent")

def test_example(dependent_resource):
    assert True

A Teardown order depends on test function order

B Teardown order is correct: expensive_resource teardown runs before dependent_resource teardown

C Fixtures with same scope teardown in random order

D Teardown order is reversed: dependent_resource teardown runs before expensive_resource teardown

💡 Hint

Think about fixture dependency and teardown sequence.

Pytest tears down fixtures in reverse order of setup. Since dependent_resource uses expensive_resource, dependent_resource is torn down first, then expensive_resource.

❓ framework

advanced

Best way to share a database connection across tests

You want to share a single expensive database connection across multiple test files in pytest. Which fixture scope and method is best?

A Use a fixture with scope='function' that opens and closes connection per test

B Use a fixture with scope='session' that opens connection once and yields it

C Use a fixture with scope='module' but open connection in each test manually

D Use a fixture with scope='class' that opens connection once per test class

💡 Hint

Think about how often you want the expensive setup to run.

Scope='session' runs once per test session, ideal for expensive resources shared across all tests and files.

🧠 Conceptual

expert

Why use autouse fixtures for shared expensive resources?

What is the main advantage of using an autouse fixture with an expensive resource in pytest?

A It automatically provides the resource to all tests without needing explicit parameters

B It runs the fixture setup multiple times per test to ensure freshness

C It disables teardown to keep the resource alive after tests

D It forces tests to fail if they do not use the resource

💡 Hint

Think about convenience and test code simplicity.

Autouse fixtures run automatically for all tests in scope, so tests get the resource without needing to mention it explicitly.