Parametrized fixtures in PyTest - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of a parametrized fixture with multiple values

What will be the output when running this pytest test with the given parametrized fixture?

PyTest

import pytest

@pytest.fixture(params=[1, 2, 3])
def number(request):
    return request.param

def test_is_positive(number):
    assert number > 0
    print(f"Testing with number: {number}")

A Test runs once printing: Testing with number: [1, 2, 3]

B Test runs 3 times printing: Testing with number: 1, Testing with number: 2, Testing with number: 3

C Test runs 3 times but fails on number 1

D Test runs 1 time and fails because number is not defined

💡 Hint

Remember that pytest runs the test once for each parameter in the fixture.

The fixture 'number' is parametrized with three values: 1, 2, and 3. The test runs once per value, printing the message each time. Since all numbers are positive, the assertion passes each time.

❓ assertion

intermediate

Correct assertion for a parametrized fixture test

Given this parametrized fixture, which assertion correctly verifies the fixture value is even?

PyTest

import pytest

@pytest.fixture(params=[2, 4, 5])
def even_number(request):
    return request.param

def test_even(even_number):
    # Which assertion is correct here?

A assert even_number % 2 == 0

B assert even_number % 2 != 0

C assert even_number == 5

D assert even_number > 5

💡 Hint

An even number is divisible by 2 with no remainder.

The assertion 'assert even_number % 2 == 0' checks if the number is even. Since the fixture includes 5, which is odd, this test will fail for that parameter, which is expected behavior.

🔧 Debug

advanced

Identify the error in this parametrized fixture usage

What error will this pytest code raise when executed?

PyTest

import pytest

@pytest.fixture(params=["a", "b", "c"])
def letter(request):
    return letter

def test_letter(letter):
    assert letter in ['a', 'b', 'c']

A AssertionError because letter is not in the list

B TypeError because 'letter' is not iterable

C RecursionError due to fixture returning itself

D No error, test passes

💡 Hint

Check what the fixture returns inside its function body.

The fixture function 'letter' returns itself instead of the parameter value. This causes infinite recursion when pytest tries to resolve the fixture, leading to a RecursionError.

❓ framework

advanced

Using indirect parametrization with fixtures

Which option correctly uses indirect parametrization to pass parameters to a fixture?

PyTest

import pytest

@pytest.fixture
def data(request):
    return request.param * 2

def test_data(data):
    assert data in [2, 4, 6]

A

@pytest.mark.parametrize('data', [1, 2, 3])
def test_data(data):
    assert data in [2, 4, 6]

B

@pytest.mark.parametrize('data', [2, 4, 6], indirect=False)
def test_data(data):
    assert data in [2, 4, 6]

C

@pytest.mark.parametrize('request', [1, 2, 3], indirect=True)
def test_data(data):
    assert data in [2, 4, 6]

D

@pytest.mark.parametrize('data', [1, 2, 3], indirect=True)
def test_data(data):
    assert data in [2, 4, 6]

💡 Hint

Indirect parametrization tells pytest to pass parameters to the fixture, not directly to the test.

Option D uses indirect=True to pass the parameters to the fixture 'data'. The fixture doubles the parameter, so the test checks for doubled values 2, 4, 6. Other options either miss indirect=True or use wrong parameter names.

🧠 Conceptual

expert

Why use parametrized fixtures instead of simple parametrized tests?

Which is the best explanation for using parametrized fixtures over parametrized tests in pytest?

A Parametrized fixtures allow sharing setup code and parameters across multiple tests, improving code reuse and clarity.

B Parametrized fixtures run tests faster by skipping setup steps.

C Parametrized fixtures prevent tests from running multiple times.

D Parametrized fixtures automatically generate test reports without assertions.

💡 Hint

Think about how fixtures help organize setup and data for tests.

Parametrized fixtures let you define setup logic once and reuse it with different data in many tests. This reduces duplication and makes tests easier to maintain. Other options are incorrect because fixtures don't skip setup, don't remove assertions, and don't prevent multiple runs.