Fixture organization in FastAPI - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

How does fixture scope affect FastAPI test client reuse?

Consider a FastAPI test setup where a client fixture is defined with different scopes. What happens when the fixture scope is set to function versus module?

FastAPI

import pytest
from fastapi.testclient import TestClient
from myapp import app

@pytest.fixture(scope="function")
def client():
    return TestClient(app)

# In tests, client is used to make requests

A With scope='module', a new TestClient instance is created for every test invocation, causing slower tests.

B With scope='function', a new TestClient instance is created for each test function, isolating state between tests.

C With scope='function', the same TestClient instance is reused across all test functions in the module.

D With scope='module', a new TestClient instance is created for each test function, increasing test isolation.

💡 Hint

Think about how pytest fixture scopes control the lifetime of the fixture object.

Setting scope='function' means pytest creates a new fixture instance for each test function, ensuring no shared state. Setting scope='module' creates one instance per module, so tests share the same client.

❓ state_output

intermediate

What is the output when a fixture modifies shared state incorrectly?

Given this fixture and test code, what will be the value of counter['count'] after running both tests?

FastAPI

import pytest

counter = {'count': 0}

@pytest.fixture(scope='module')
def shared_counter():
    counter['count'] += 1
    return counter

def test_one(shared_counter):
    assert shared_counter['count'] == 1

def test_two(shared_counter):
    assert shared_counter['count'] == 1

A counter['count'] will be 1 after both tests run because the fixture runs once per module and increments once.

B counter['count'] will be 0 because the fixture does not modify the counter correctly.

C counter['count'] will be 2 after both tests run because the fixture runs once per module.

D Tests will fail because the fixture is not returning a fresh dictionary each time.

💡 Hint

Remember that scope='module' means the fixture runs once per module, so the increment happens once.

The fixture runs once per module, so counter['count'] increments once before tests run. Both tests share the same dictionary, so after both tests, the count remains 1 during tests but after both tests, the value is 1. However, since the fixture runs once, the count increments once only. The tests expect 1, so they pass. The final value after tests is 1.

📝 Syntax

advanced

Which fixture definition causes a syntax error in FastAPI tests?

Identify the fixture definition that will cause a syntax error when used in FastAPI tests with pytest.

A

@pytest.fixture(scope='module')
def client():
    return TestClient(app)

B

)ppa(tneilCtseT nruter    
:)(tneilc fed
)'noitcnuf'=epocs(erutxif.tsetyp@

C

@pytest.fixture(scope='function')
def client():
    return TestClient(app)

D

@pytest.fixture
def client():
    return TestClient(app)

💡 Hint

Check the function definition syntax carefully.

Option C is missing parentheses in the function definition (def client:), which causes a syntax error. All other options have correct syntax.

🔧 Debug

advanced

Why does this FastAPI fixture cause tests to share unwanted state?

Examine the fixture below. Why do tests using this fixture share state unexpectedly?

FastAPI

import pytest

class Resource:
    def __init__(self):
        self.value = 0

resource = Resource()

@pytest.fixture(scope='module')
def shared_resource():
    return resource

def test_a(shared_resource):
    shared_resource.value += 1
    assert shared_resource.value == 1

def test_b(shared_resource):
    assert shared_resource.value == 0

A The fixture returns a global object, so changes persist across tests sharing the fixture.

B The fixture scope is 'module', so a new Resource instance is created for each test.

C The Resource class is immutable, so state cannot be changed between tests.

D The fixture is missing a yield statement, causing state sharing.

💡 Hint

Think about how returning a global object affects test isolation.

The fixture returns the same global resource object for all tests in the module. When test_a modifies value, test_b sees the changed value, causing unexpected shared state.

🧠 Conceptual

expert

What is the best way to organize database fixtures in FastAPI tests for isolation and performance?

In FastAPI testing, you want to organize your database fixtures to ensure each test runs with a clean state but also keep tests fast. Which approach best balances isolation and performance?

A Use a <code>function</code> scoped fixture that reuses the same database connection without cleanup.

B Use a <code>function</code> scoped fixture that creates a fresh test database and applies migrations before each test.

C Use a <code>session</code> scoped fixture that creates a test database once per test session and does not reset state between tests.

D Use a <code>module</code> scoped fixture that creates a test database once per module and rolls back transactions after each test.

💡 Hint

Consider how transaction rollbacks can speed up tests while keeping data isolated.

Using a module scoped fixture to create the test database once and then rolling back transactions after each test keeps tests isolated and fast. Creating a fresh database per test (function scope) is slow. Session scope without cleanup causes data leaks. Reusing connections without cleanup causes flaky tests.