Conftest fixtures (shared across files) in PyTest - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of shared fixture usage across test files

Given the following conftest.py fixture and two test files, what will be the output when running all tests?

PyTest

## conftest.py
import pytest

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

## test_file1.py

def test_one(resource):
    assert resource == 'resource_data'

## test_file2.py

def test_two(resource):
    assert resource == 'resource_data'

A Setup resource\nSetup resource\nTeardown resource\nTeardown resource

B Setup resource\nTeardown resource

C Setup resource\nTeardown resource\nTeardown resource

D Setup resource\nTeardown resource\nSetup resource\nTeardown resource

💡 Hint

Think about the scope='module' fixture and how many times it runs across multiple test files.

A fixture with scope='module' runs once per test module. Since conftest.py is shared, and there are two separate test files (modules), the fixture runs once per test file: setup and teardown for test_file1.py, then for test_file2.py. The output is Setup resource\nTeardown resource\nSetup resource\nTeardown resource.

❓ assertion

intermediate

Correct assertion for fixture data modification

A conftest fixture returns a list. A test modifies the list by appending an item. Which assertion correctly verifies the list content inside the test?

PyTest

import pytest

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

def test_append(sample_list):
    sample_list.append(4)
    # Which assertion is correct here?

A assert sample_list == [4, 1, 2, 3]

B assert sample_list == [1, 2, 3, 4]

C assert sample_list != [1, 2, 3, 4]

D assert sample_list is [1, 2, 3, 4]

💡 Hint

Remember how list append works and how to compare lists in Python.

The append method adds the element at the end of the list, so the list becomes [1, 2, 3, 4]. The correct way to check list equality is using '=='. Using 'is' checks identity, which is not correct here. The order matters, so [4, 1, 2, 3] is incorrect.

🔧 Debug

advanced

Identify the cause of fixture not being shared

You have a fixture in conftest.py with scope='session', but it seems to run before every test function instead of once per session. What is the most likely cause?

PyTest

## conftest.py
import pytest

@pytest.fixture(scope='session')
def db_connection():
    print('Connecting to DB')
    yield 'db_conn'
    print('Closing DB')

## test_module.py

def test_a(db_connection):
    assert db_connection == 'db_conn'

def test_b(db_connection):
    assert db_connection == 'db_conn'

A The fixture is defined in conftest.py but tests are run with '-k' option filtering only one test at a time.

B The fixture is not imported in test_module.py, so it runs multiple times.

C The fixture scope='session' is ignored if tests are in different files.

D The fixture uses yield, which forces it to run before every test.

💡 Hint

Think about how pytest runs tests and how filtering affects fixture scope.

When pytest runs tests with '-k' or other filters that select individual tests, it may create separate sessions for each run, causing session-scoped fixtures to run multiple times. The fixture is correctly defined and shared, but the test run method causes multiple runs.

❓ framework

advanced

Best practice for fixture sharing in large projects

In a large pytest project with many test files, where should you place fixtures that need to be shared across multiple test files?

A Put all fixtures in a separate Python module and import them manually in each test file.

B Define fixtures inside each test file that uses them to avoid conflicts.

C Place shared fixtures in a conftest.py file at the root or common directory.

D Define fixtures inside test classes to scope them to tests only.

💡 Hint

Think about pytest's automatic fixture discovery.

Pytest automatically discovers fixtures defined in conftest.py files in the directory tree. Placing shared fixtures in conftest.py at a common root allows all tests below to use them without imports. Defining fixtures inside test files or classes limits sharing. Manual imports are possible but less convenient.

🧠 Conceptual

expert

Understanding fixture scope and autouse behavior

Consider a fixture in conftest.py defined with scope='function' and autouse=True. How many times will this fixture run if you have 3 test functions in 2 different test files?

A 3 times total, once per test function across all files.

B 6 times total, once per test function in each file separately.

C Once per test file, so 2 times total.

D Once per test session, so only 1 time.

💡 Hint

Remember what scope='function' and autouse=True mean for fixture execution.

A fixture with scope='function' runs before each test function. Autouse=True means it runs automatically without needing to be requested. There are 3 test functions total across the 2 files, so it runs 3 times.

Practice

1. What is the main purpose of placing fixtures in a conftest.py file in pytest?

easy

A. To run tests in parallel automatically

B. To share setup code automatically across multiple test files without importing

C. To store test data in a database

D. To define test cases only for one specific test file

Solution

1. Step 1: Understand the role of conftest.py

   The conftest.py file is used to define fixtures that can be shared across multiple test files without needing explicit imports.

2. Step 2: Identify the purpose of sharing setup code

   Sharing setup code helps avoid repetition and makes tests cleaner and easier to maintain.

3. Final Answer:

   To share setup code automatically across multiple test files without importing -> Option B

4. Quick Check:

   conftest.py shares fixtures automatically [OK]

Hint: Remember: conftest.py shares fixtures without imports [OK]

Common Mistakes:

• Thinking conftest.py runs tests in parallel
• Believing conftest.py stores test data
• Assuming fixtures in conftest.py are for one file only

2. Which of the following is the correct way to define a fixture in conftest.py for sharing across test files?

easy

A. def my_fixture(): return 42

B. class my_fixture: pass

C. @pytest.fixture
def my_fixture(): return 42

D. import pytest
my_fixture = 42

Solution

1. Step 1: Recall fixture syntax in pytest

   Fixtures must be decorated with @pytest.fixture to be recognized by pytest.

2. Step 2: Check each option

   @pytest.fixture def my_fixture(): return 42 correctly uses the decorator and defines a function returning a value. Other options miss the decorator or use wrong syntax.

3. Final Answer:

   @pytest.fixture\ndef my_fixture(): return 42 -> Option C

4. Quick Check:

   Fixtures need @pytest.fixture decorator [OK]

Hint: Always use @pytest.fixture decorator for fixtures [OK]

Common Mistakes:

• Forgetting the @pytest.fixture decorator
• Defining fixtures as classes without decorator
• Assigning fixture values without function

3. Given the following conftest.py fixture and test file, what will be the output when running pytest?

-- conftest.py --
import pytest

@pytest.fixture
def number():
    return 5

-- test_sample.py --

def test_double(number):
    assert number * 2 == 10

def test_triple(number):
    assert number * 3 == 15

medium

A. Both tests pass

B. Both tests fail

C. test_double passes, test_triple fails

D. test_double fails, test_triple passes

Solution

1. Step 1: Understand fixture usage

   The fixture number returns 5 and is shared automatically via conftest.py.

2. Step 2: Evaluate test assertions

   test_double checks 5*2 == 10 (True), test_triple checks 5*3 == 15 (True). Both assertions are correct.

3. Final Answer:

   Both tests pass -> Option A

4. Quick Check:

   Fixture returns 5, assertions match [OK]

Hint: Check fixture value and test assertions carefully [OK]

Common Mistakes:

• Assuming fixture is not shared without import
• Miscalculating expected assertion values
• Confusing test pass/fail logic

4. You have a fixture defined in conftest.py as follows:

import pytest

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

In your test file, you wrote:

def test_sum(data):
    assert sum(data) == 10

What is the problem and how to fix it?

medium

A. Assertion is wrong; sum([1,2,3]) is 6, so change 10 to 6

B. Fixture not imported; add from conftest import data

C. Fixture must be a class, not a function

D. sum() cannot be used on lists

Solution

1. Step 1: Check the fixture return value

   The fixture data returns the list [1, 2, 3].

2. Step 2: Calculate the sum and compare with assertion

   sum([1, 2, 3]) equals 6, but the test asserts it equals 10, which is incorrect.

3. Final Answer:

   Assertion is wrong; sum([1,2,3]) is 6, so change 10 to 6 -> Option A

4. Quick Check:

   sum([1,2,3]) = 6, fix assertion [OK]

Hint: Verify expected values match fixture data [OK]

Common Mistakes:

• Thinking fixture must be imported explicitly
• Assuming sum() can't handle lists
• Changing fixture type unnecessarily

5. You want to share a fixture that provides a database connection across multiple test files. You place this fixture in conftest.py:

import pytest

@pytest.fixture(scope="session")
def db_connection():
    conn = create_connection()
    yield conn
    conn.close()

What is the best reason to use scope="session" here?

hard

A. To run tests in parallel using the same connection

B. To create a new connection for every test function

C. To close the connection before each test

D. To create the connection once per test session and reuse it in all tests

Solution

1. Step 1: Understand fixture scopes in pytest

   Scope "session" means the fixture is created once for the entire test run and shared across all tests.

2. Step 2: Apply to database connection use case

   Creating the connection once saves time and resources, and closing it after all tests is efficient.

3. Final Answer:

   To create the connection once per test session and reuse it in all tests -> Option D

4. Quick Check:

   Session scope = one setup per test run [OK]

Hint: Use session scope for expensive setup reused by all tests [OK]

Common Mistakes:

• Thinking session scope creates new instance per test
• Assuming connection closes before each test
• Confusing scope with parallel test execution