prompts/.github/prompts/pytest-fill-scaffold.prompt.md

name, description, argument-hint, agent

name	description	argument-hint	agent
Pytest Fill Scaffold	Fill scaffolded pytest test methods with assertions, fixtures, and minimal test data while preserving concise test names and one-line intent docstrings.	Target test file(s) under tests plus stack (pure-python, fastapi, sqlalchemy-sync, sqlalchemy-async, or mixed)	agent

Pytest Fill Scaffold

Use this prompt after test scaffolding exists and method names/docstrings are already in place.

Inputs

• Target test file(s) under tests/.
• Stack type:
  • pure-python
  • fastapi
  • sqlalchemy-sync
  • sqlalchemy-async
  • mixed
• Optional constraints:
  • keep implementation minimal vs comprehensive
  • marker lane target (unit, integration, smoke)

Required References

Load these in order and use only what matches the task:

1. Core defaults: pytest scaffolding skill
2. Naming/hierarchy preservation: naming and organization
3. Baseline pytest fixtures/markers: pytest docs notes
4. FastAPI-specific behavior (only when needed): fastapi testing
5. SQLAlchemy-specific behavior (only when needed): sqlalchemy testing

Workflow

1. Inspect target files and treat human-reviewed docstring-only scaffolds as invariant.
2. Convert each scaffolded method into an executable test with a single behavior focus.
3. Keep one-line docstrings for class and method intent.
4. Add or refine fixtures at the nearest useful scope:
   • global in tests/conftest.py only when broadly reusable
   • subtree conftest.py for domain-specific fixtures
5. Assign markers consistent with cost and dependencies:
   • unit for pure logic
   • integration for framework/DB contracts
   • smoke for thin critical-path checks
6. Validate in this order:
   • uv run pytest --collect-only -q
   • uv run pytest -m unit -q when unit tests are touched
   • uv run pytest -q if dependencies are available

Authoring Rules

• Prefer deterministic tests and explicit setup/teardown.
• Keep assertions precise and readable.
• Do not overfit tests to private implementation details.
• If a scaffolded class or method has only a docstring body, treat its name and hierarchy as locked.
• Do not rename, move, merge, split, or re-nest docstring-only scaffolded tests unless explicitly requested.
• Preserve existing one-line docstrings on scaffolded classes and methods unless they are factually incorrect.
• If stack details are missing and would change fixture strategy, ask one concise clarifying question before editing.

Output Format

Return:

1. Files updated.
2. Fixture and marker decisions.
3. Which references were used and why.
4. Validation command results.
5. Risks or open questions.