Testing

Enables data-driven testing by running one test function against many input-output combinations without duplicating test code.

Unit testing: verifying a pure function across a range of inputs and expected outputs. API testing: checking endpoint responses for multiple request payloads. Data validation: asserting a parser or transformer handles various edge-case records correctly.

pytest test suites, data-driven testing, Python projects with parameterized test coverage requirements.

@pytest.mark.parametrize(argnames, argvalues) def test_function(arg1, arg2, expected): assert function_under_test(arg1, arg2) == expected

@pytest.mark.parametrize(..., [...]) def ...(....): assert ...

argnames: comma-separated string of parameter names or list of strings, argvalues: list of tuples/lists where each element maps to one argname, arg1/arg2/expected: parameter names matching argnames order

• pytest.fixture
• pytest.raises
• pytest.mark.xfail
• pytest.mark.skipif
• assert
• ids keyword

• pytest.param(value
• marks=...
• id=...) for per-case marks and IDs — adds per-case metadata at the cost of verbosity. Hypothesis strategies for property-based fuzzing — generates random inputs instead of fixed lists
• trading explicitness for broader coverage.

Passing argnames as a list instead of a comma-separated string — pytest raises a TypeError about invalid parametrize format. Mismatching the number of values in a tuple to the number of argnames — causes ValueError at collection time. Forgetting to add the parameters as function arguments — results in TypeError at test execution because the test function receives unexpected positional arguments.

pytest.mark.xfail: marks a test as expected to fail rather than running it with multiple inputs. unittest.TestCase.subTest: JUnit-style subtest context manager — less declarative, no separate test IDs in reports. Hypothesis @given: property-based testing with random input generation instead of fixed datasets.

Coming from Java/JUnit: may expect @ParameterizedTest with @MethodSource or @ValueSource syntax — pytest uses a single decorator with inline value tuples rather than separate source annotations. Coming from nose: may look for nose.tools.nottest or nose-parameterized — pytest.parametrize is the native equivalent with different argument ordering.

• pytest.mark.parametrize
• pytest.param
• pytest.mark.xfail
• pytest.mark.skipif
• pytest.fixture

Avoid parametrize when each case requires fundamentally different setup logic — use separate test functions instead. Large argvalue lists generate many test IDs that can bloat pytest output and slow collection; use ids keyword to keep names short. Combining multiple parametrize decorators on one function creates a Cartesian product, which can explode test count unexpectedly.

Reduces test code duplication, makes coverage gaps visible (each case appears as a separate line in pytest verbose output), and ensures new edge cases are added in one place rather than scattered across copy-pasted test functions.

Like a mail-merge for tests: write the letter once, supply a list of recipients, and pytest prints a separate copy for each.

The ids keyword argument accepts a list of strings or a callable to customize test IDs shown in reports, which is essential for readability when argvalues contain complex objects.

pytest.param(value, marks=pytest.mark.xfail(), id='case') for per-case marks and custom IDs; Hypothesis @given for property-based testing with generated inputs.