Generates multiple invocations of a test function, each with a distinct set of argument values supplied by the decorator.

Specifies the sets of input arguments for a parametrized test, enabling data‑driven testing without writing duplicate test functions.

When you need to verify the same logic across multiple input combinations, such as testing a function with various edge cases.

Placed directly above a test function definition in a pytest test module; the decorated function must accept the parameter names declared in the decorator.

@pytest.mark.parametrize('param1,param2,...', [(val1,val2,...), ...])

@pytest.mark.parametrize('param_names', [(value_set)]) where param_names is a comma‑separated string of parameter names and each tuple provides corresponding values.

param_names: string of comma‑separated parameter names; values: list of tuples each matching the arity of param_names.

• @pytest.fixture
• def test_
• import pytest
• assert
• pytest.param

• Using lists instead of tuples for each parameter set
• using pytest.param to add marks or custom IDs
• employing the ids parameter to customize test identifiers.

1. Mismatch between number of parameter names and values per tuple (cause: misunderstanding arity) → ValueError during test collection.\n2. Forgetting to import pytest (cause: oversight) → NameError when the test module loads.\n3. Using lists instead of tuples for each parameter set (cause: confusion about required syntax) → TypeError during argument unpacking.\n4. Omitting test function parameters that match the declared names (cause: copy‑paste error) → fixture lookup failure.\n5. Using duplicate parameter names (cause: typo) → unexpected argument binding and test failures.

@pytest.fixture – provides setup/fixture data rather than varying test inputs; @pytest.mark.skip – unconditionally skips a test instead of generating multiple cases; @pytest.mark.parametrize with ids – same core behavior but adds readable test names; unittest’s @parameterized.expand – similar concept but uses a different syntax and requires the parameterized library.

Coming from unittest: may expect @parameterized.expand or @data decorators → use pytest.mark.parametrize with tuples; Coming from JavaScript testing frameworks: may look for array‑of‑objects syntax → pytest expects tuples or lists of values; Coming from Rust’s test harness: may expect attribute‑style macros → pytest uses decorator syntax.

• pytest.mark.parametrize
• pytest.param
• pytest.fixture
• parametrize with ids

1. Avoid when the number of test cases is very small and explicit test functions are clearer; 2. The overhead is minimal (test collection time) but very large numbers of generated tests can increase collection time and memory usage; 3. Boundary condition: if any parameter set contains values that cannot be unpacked (e.g., mismatched types), test collection will fail with a TypeError.

Enables concise, maintainable test suites by eliminating boilerplate test functions, making it easy to add new cases and ensuring consistent test logic across all inputs.

Think of @pytest.mark.parametrize as a cookie cutter that stamps out many identical‑shaped cookies (test cases) from one dough (test function).

The ids argument can be used to generate human‑readable test names, improving traceability in test reports.

Progress to using pytest.param with marks (e.g., pytest.mark.skip) or the ids parameter for more expressive test cases; later consider fixture‑based parameterization for complex setup.