Parametrization Without the Cartesian-Product Trap

Start from behavioral partitions

Before writing decorators, divide the input space into equivalence classes and boundaries. For a transfer amount, meaningful classes might include zero, the smallest accepted unit, a normal amount, the exact available balance, and one unit above it. Twenty random positive numbers probably exercise the same branch. One representative from each class is easier to defend and faster to diagnose.

Parameters should encode an observable contract. A row that changes an input without changing a path, invariant, or expected outcome needs a reason to exist. This is especially important in API suites, where combinations of role, resource state, payload variant, and transport condition can explode into hundreds of cases. List the dimensions first, then select interactions based on risk rather than generating their full Cartesian product automatically.

• Use boundary values around validation thresholds.
• Represent authorization roles that genuinely have different permissions.
• Cover resource states that change behavior, such as active, locked, and deleted.
• Add pairwise or targeted interaction cases when two dimensions can influence each other.

Make every case identifiable in a failure report

Default IDs based on raw parameter values become noisy when rows contain dictionaries, models, or long strings. Explicit IDs turn a report into a decision log. A failure named overdraft_rejected is immediately more useful than payload3. IDs should describe the scenario and expected behavior, not repeat all input fields.

Readable IDs also improve focused execution. A developer can select a single behavior with pytest's keyword filtering, reproduce it locally, and discuss it in a pull request without counting rows. Treat an ID as a stable human interface, but avoid coupling external tooling to it as though it were a permanent database key; the scenario wording can legitimately evolve.

import pytest

@pytest.mark.parametrize(
    ("amount", "balance", "expected_status"),
    [
        pytest.param(1, 100, 201, id="minimum-accepted"),
        pytest.param(100, 100, 201, id="exact-balance"),
        pytest.param(101, 100, 422, id="overdraft-rejected"),
    ],
)
def test_transfer_amount(api_client, amount, balance, expected_status):
    response = api_client.post(
        "/transfers",
        json={"amount": amount, "available_balance": balance},
    )
    assert response.status_code == expected_status

Keep inputs and expectations close

A row should tell a coherent story. When parameters are spread across stacked decorators, pytest produces a Cartesian product. That is perfect when every combination is meaningful and expected. It is misleading when some combinations are impossible or redundant. In that case, define complete scenario rows or generate a reviewed case list in one place.

Expected outcomes belong beside inputs when the mapping is part of the contract. Avoid recomputing the expected result with logic that mirrors the system under test; two copies of the same mistake can agree. Prefer explicit expected status, error type, or state transition. For complex results, assert stable invariants and a few important fields rather than serializing an entire response snapshot that changes for unrelated reasons.

Use indirect parametrization only for setup variation

Indirect parametrization passes a parameter into a fixture via request.param. It can be effective when a scenario needs a differently configured dependency—for example, an account fixture created in a locked or active state. It is not a general-purpose way to hide data creation. Overuse forces readers to jump between the test and conftest.py to discover what a row means.

A practical rule is to keep the business-facing value in the test and move only the environment construction behind a fixture. If a status string is sufficient for the fixture to construct the account, the report should still show active-account or locked-account as a parameter ID. The test remains a description of behavior while the fixture remains an implementation of setup.

Control matrix growth intentionally

A large matrix has costs beyond runtime. It increases failure noise, test-data contention, and maintenance when the contract changes. Tag slower interaction cases separately, run the fast boundary matrix on every change, and schedule broader compatibility coverage when appropriate. This is coverage layering, not an excuse to hide important cases from continuous integration.

Review matrices like code. Remove rows that protect no distinct rule, add a comment when a strange boundary represents a known protocol limit, and check that IDs still match expectations after edits. Parametrization should make intent more visible. If the decorator takes longer to understand than separate tests, splitting the behaviors may be the clearer design.