Handling shared resources in PyTest - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of pytest fixture with shared resource

Consider the following pytest code using a fixture that manages a shared resource. What will be the output when running the test?

PyTest

import pytest

shared_list = []

@pytest.fixture(scope="module")
def resource():
    shared_list.append(1)
    yield shared_list
    shared_list.clear()

def test_one(resource):
    resource.append(2)
    assert resource == [1, 2]

def test_two(resource):
    resource.append(3)
    assert resource == [1, 3]

A Both test_one and test_two fail with AssertionError

B Both test_one and test_two pass

C test_one fails with AssertionError, test_two passes

D test_one passes, test_two fails with AssertionError

💡 Hint

Think about how the shared_list is modified and when it is cleared.

The fixture has module scope, so shared_list is initialized once with [1]. test_one appends 2, so resource is [1, 2]. test_two runs next and appends 3, so resource becomes [1, 2, 3]. The assertion in test_two expects [1, 3], so it fails.

❓ assertion

intermediate

Correct assertion for shared file content

You have a shared file resource used in multiple tests. Which assertion correctly verifies that the file content includes the string 'success' after writing?

PyTest

def test_write_file(shared_file):
    shared_file.write('operation success')
    shared_file.seek(0)
    content = shared_file.read()

A assert 'success' in content

B assert content == 'success'

C assert content.startswith('success')

D assert content.endswith('success')

💡 Hint

The file content may have other text besides 'success'.

The content includes the word 'success' but also other text. Using 'in' checks for substring presence, which is correct here.

🔧 Debug

advanced

Identify the cause of test interference with shared database connection

Two tests share a database connection fixture with function scope. Test A inserts a row but does not rollback. Test B expects an empty table but fails. What is the most likely cause?

PyTest

import pytest

@pytest.fixture(scope='function')
def db_connection():
    conn = create_connection()
    yield conn
    conn.close()

def test_a(db_connection):
    db_connection.execute('INSERT INTO users VALUES (1, "Alice")')
    # missing rollback

def test_b(db_connection):
    result = db_connection.execute('SELECT * FROM users')
    assert len(result.fetchall()) == 0

A Test A did not rollback, so data persists and affects Test B

B The fixture scope should be module, not function

C Test B has a wrong assertion expecting empty table

D The connection is closed too early in Test A

💡 Hint

Think about transaction handling and test isolation.

Since Test A inserts data but does not rollback, the inserted row remains in the database. Test B sees this data and fails its assertion expecting an empty table.

❓ framework

advanced

Best pytest fixture scope for expensive shared resource

You have a resource that takes 10 minutes to set up and can be safely shared across all tests in a module. Which pytest fixture scope is best to use?

A scope='function' to isolate each test

B scope='module' to share resource across all tests in the module

C scope='session' to share resource across all test sessions

D scope='class' to share resource across tests in a class

💡 Hint

Choose a scope that balances setup time and test isolation.

Module scope creates the resource once per module, which is efficient and safe here. Function scope is too frequent, session scope may be too broad, and class scope depends on test organization.

🧠 Conceptual

expert

Handling flaky tests caused by shared resource contention

You notice intermittent test failures caused by multiple tests accessing a shared resource concurrently. What is the best approach to handle this in pytest?

A Use pytest-xdist to run tests in parallel to reduce test time

B Mark flaky tests as expected failures to ignore them

C Add locks or synchronization in fixtures to serialize access to the shared resource

D Increase the fixture scope to session to share the resource more broadly

💡 Hint

Think about how to prevent concurrent access issues.

Adding locks or synchronization ensures only one test accesses the shared resource at a time, preventing race conditions and flaky failures.