What if you could test dozens of cases with just one simple test function?
Why Parametrized fixtures in PyTest? - Purpose & Use Cases
Imagine you have a function that needs to be tested with many different inputs. You write separate test functions for each input manually, repeating similar code again and again.
This manual approach is slow and boring. You might forget to test some cases or make mistakes copying code. It's hard to keep tests organized and update them when inputs change.
Parametrized tests let you write one test that runs automatically with many inputs. This saves time, reduces errors, and keeps tests clean and easy to maintain.
def test_add_1(): assert add(1, 2) == 3 def test_add_2(): assert add(3, 4) == 7
@pytest.mark.parametrize('a,b,expected', [(1,2,3), (3,4,7)]) def test_add(a, b, expected): assert add(a, b) == expected
You can quickly test many input combinations with one simple test, making your testing faster and more reliable.
Testing a login form with different usernames and passwords becomes easy and automatic, ensuring all cases are covered without writing repetitive code.
Manual tests for many inputs are slow and error-prone.
Parametrized tests run one test with many inputs automatically.
This makes tests cleaner, faster, and easier to maintain.
Practice
@pytest.fixture(params=[...]) in pytest?Solution
Step 1: Understand the role of parametrized fixtures
Parametrized fixtures allow running a test function multiple times with different data inputs automatically.Step 2: Match the purpose with the options
To run the same test multiple times with different input data correctly describes this behavior, while others describe unrelated pytest features.Final Answer:
To run the same test multiple times with different input data -> Option AQuick Check:
Parametrized fixtures = run test multiple times [OK]
- Confusing parametrized fixtures with test skipping
- Thinking it groups tests instead of repeating them
- Mixing up with expected failure markers
Solution
Step 1: Identify correct decorator and parameter name
The correct decorator is@pytest.fixturewith the keywordparamsas a list.Step 2: Check function signature and usage
The fixture function must acceptrequestand returnrequest.paramto access each parameter value.Final Answer:
@pytest.fixture(params=[1, 2, 3])\ndef data(request):\n return request.param -> Option CQuick Check:
Use @pytest.fixture(params=[...]) and request.param [OK]
- Using @pytest.param instead of @pytest.fixture
- Misspelling 'params' as 'param'
- Not including 'request' parameter in fixture function
- Returning undefined variable instead of request.param
import pytest
@pytest.fixture(params=[10, 20])
def number(request):
return request.param
def test_double(number):
assert number * 2 in [20, 40]Solution
Step 1: Understand parametrized fixture values
The fixture 'number' will run the test twice: once with 10, once with 20.Step 2: Evaluate the assertion for each value
For 10: 10*2=20, which is in [20,40]. For 20: 20*2=40, also in [20,40]. Both assertions pass.Final Answer:
Both tests pass -> Option DQuick Check:
10*2=20 and 20*2=40 both in list [OK]
- Assuming only one test runs
- Misreading the assertion condition
- Forgetting fixture runs test multiple times
@pytest.fixture(params=["a", "b"])
def letter():
return param
def test_letter(letter):
assert letter in ["a", "b"]Solution
Step 1: Check fixture function parameters
The fixture usesparams, so it must acceptrequestto accessrequest.param.Step 2: Identify incorrect return statement
The function returnsparam, which is undefined. It should returnrequest.param.Final Answer:
Missing 'request' parameter in fixture function -> Option BQuick Check:
Parametrized fixture needs 'request' param [OK]
- Not including 'request' parameter in fixture
- Returning undefined variable instead of request.param
- Confusing fixture decorator names
Solution
Step 1: Understand skipping inside parametrized fixtures
Inside the fixture, you can callpytest.skip()when the current parameter is invalid to skip that test run.Step 2: Compare with other options
Removing invalid data beforehand avoids testing them but doesn't show skipped tests. Raising exceptions fails tests, not skip. Usingskipifon test function is less flexible for per-parameter skipping.Final Answer:
Use pytest.skip() inside the fixture when data is invalid -> Option AQuick Check:
Call pytest.skip() in fixture to skip invalid params [OK]
- Removing invalid data silently instead of skipping
- Raising exceptions instead of skipping
- Using skipif without parameter-specific logic
Ready to prove it?
Pass the test and this pattern moves unknown
