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.

Practice

1. What is the main purpose of using fixtures in FastAPI testing with pytest?

easy

A. To deploy the FastAPI app to production

B. To prepare resources and keep test code clean

C. To write the main application logic

D. To create database models

Solution

1. Step 1: Understand the role of fixtures

   Fixtures are used to prepare resources like database connections or test clients before tests run.

2. Step 2: Recognize their benefit in test code

   They help keep test code clean by avoiding repeated setup code in each test.

3. Final Answer:

   To prepare resources and keep test code clean -> Option B

4. Quick Check:

   Fixtures = prepare resources + clean tests [OK]

Hint: Fixtures set up test resources to avoid repeating code [OK]

Common Mistakes:

• Confusing fixtures with app logic
• Thinking fixtures deploy the app
• Using fixtures to define database models

2. Which of the following is the correct way to declare a fixture in pytest for FastAPI tests?

easy

A. class MyFixture: pass

B. def my_fixture(): return client

C. @app.get('/test')
def my_fixture(): return client

D. @pytest.fixture
def my_fixture(): yield client

Solution

1. Step 1: Identify pytest fixture syntax

   Fixtures require the decorator @pytest.fixture before the function.

2. Step 2: Recognize yield usage for setup/teardown

   Using yield allows setup before and teardown after the test.

3. Final Answer:

   @pytest.fixture\ndef my_fixture(): yield client -> Option D

4. Quick Check:

   Use @pytest.fixture and yield for fixtures [OK]

Hint: Use @pytest.fixture decorator and yield inside function [OK]

Common Mistakes:

• Missing @pytest.fixture decorator
• Using FastAPI route decorators instead
• Declaring fixture as a class without decorator

3. Given this conftest.py fixture code:

import pytest

@pytest.fixture
def client():
    from fastapi.testclient import TestClient
    from myapp.main import app
    with TestClient(app) as c:
        yield c

What will client.get('/items') return inside a test?

medium

A. A TestClient response object for the '/items' endpoint

B. A syntax error because yield is used incorrectly

C. An exception because app is not imported

D. None, because the fixture does not return anything

Solution

1. Step 1: Analyze the fixture setup

   The fixture creates a TestClient instance for the FastAPI app and yields it for use in tests.

2. Step 2: Understand what client.get('/items') does

   Calling client.get('/items') sends a test HTTP GET request to the '/items' route and returns a response object.

3. Final Answer:

   A TestClient response object for the '/items' endpoint -> Option A

4. Quick Check:

   Fixture yields TestClient, so client.get returns response [OK]

Hint: Fixture yields TestClient; get() returns response object [OK]

Common Mistakes:

• Thinking yield causes syntax error
• Assuming fixture returns None
• Forgetting to import app in fixture

4. Consider this fixture code in conftest.py:

import pytest

@pytest.fixture
def db():
    connection = connect_to_db()
    yield connection
    connection.close()

When running tests, you get an error: NameError: name 'connect_to_db' is not defined. How do you fix it?

medium

A. Import or define the function connect_to_db before using it

B. Remove yield and return connection instead

C. Change fixture to a class instead of a function

D. Rename the fixture to database()

Solution

1. Step 1: Identify cause of NameError

   The error means the function connect_to_db is not defined or imported in the file.

2. Step 2: Fix by importing or defining connect_to_db

   To fix, add the proper import statement or define the function before using it in the fixture.

3. Final Answer:

   Import or define the function connect_to_db before using it -> Option A

4. Quick Check:

   NameError means missing import or definition [OK]

Hint: NameError means missing import or definition [OK]

Common Mistakes:

• Removing yield does not fix NameError
• Changing fixture name won't fix missing function
• Converting to class does not solve missing import

5. You want to share a database fixture across multiple test files in FastAPI. Which is the best way to organize it?

hard

A. Put the fixture inside the main FastAPI app file

B. Copy the fixture code into every test file

C. Define the fixture in conftest.py at the root test folder

D. Define the fixture inside each test function

Solution

1. Step 1: Understand fixture sharing in pytest

   Fixtures defined in conftest.py are automatically discovered and shared across test files in the same folder or subfolders.

2. Step 2: Recognize why other options are poor

   Copying code duplicates it, defining inside test functions prevents reuse, and putting fixtures in app files mixes concerns.

3. Final Answer:

   Define the fixture in conftest.py at the root test folder -> Option C

4. Quick Check:

   conftest.py shares fixtures across tests [OK]

Hint: Use conftest.py to share fixtures across test files [OK]

Common Mistakes:

• Duplicating fixture code in every test file
• Defining fixtures inside test functions
• Mixing fixtures with app code