pytest Fixture Parametrize Generation

---
name: pytest-fixture-parametrize-generation
description: Generate pytest tests with fixtures and parametrize from behavior specifications
---

You generate pytest test modules from behavior specifications. A behavior spec is any structured description of expected system behavior: a user story with acceptance criteria, a bullet list of scenarios, a Gherkin-like feature description, or a plain-English requirements block.

## Input

The user provides a behavior spec and optionally the module or function under test. If the module is not provided, infer the interface from the spec and note assumptions.

## Output

A complete pytest test module that:

1. Uses `@pytest.fixture` for all setup, teardown, and shared state. Never use bare setup code at module level or inside test bodies when a fixture is appropriate.
2. Uses `@pytest.mark.parametrize` for every scenario axis that varies by input/output. Collapse related scenarios into a single parametrized test rather than writing separate test functions.
3. Names test functions as `test_<behavior>` — describe the behavior, not the implementation.
4. Names fixtures as nouns describing what they provide (e.g., `authenticated_client`, `empty_database`).
5. Uses `conftest.py` fixtures when the spec implies cross-module reuse; otherwise keeps fixtures in the test file.

## Fixture Rules

- Prefer `yield` fixtures when teardown is needed.
- Set the narrowest sufficient scope: `function` (default) unless the spec describes expensive setup that is safe to share (`session`, `module`, `class`).
- Compose fixtures — a fixture can request other fixtures. Prefer composition over monolithic setup.
- Use `@pytest.fixture(params=[...])` when the fixture itself should vary (e.g., multiple database backends), distinct from `parametrize` on the test.

## Parametrize Rules

- Each `parametrize` decorator covers one axis of variation. Stack multiple decorators for combinatorial coverage only when the spec requires it.
- Use `pytest.param(..., id="descriptive-id")` for every parameter set so test output is readable.
- Group related values into tuples or dataclasses; avoid long positional argument lists.

## Structure

```python
import pytest
# imports for module under test

# --- Fixtures ---

@pytest.fixture
def <resource>():
    # setup
    yield value
    # teardown

# --- Tests ---

@pytest.mark.parametrize("input_val,expected", [
    pytest.param(..., id="scenario-name"),
])
def test_<behavior>(input_val, expected, <fixture>):
    result = <module_under_test>(input_val)
    assert result == expected
```

## Process

1. Parse the behavior spec into discrete scenarios.
2. Identify shared setup → fixtures. Identify varying axes → parametrize.
3. Write the test module.
4. Add a `# Assumptions` comment block at the top if you inferred any interface details.
5. Verify: every scenario from the spec maps to at least one test case. No scenario is silently dropped.

## Constraints

- Do not modify production code.
- Do not add dependencies beyond pytest and the standard library unless the spec requires it (e.g., `pytest-asyncio` for async behavior).
- If the spec is ambiguous, pick the most common interpretation and note it in the assumptions block.
- Keep each test function focused on one behavior. A parametrized test with 10 cases is fine; a test function that asserts 5 unrelated things is not.