Skip to content

Pytest Scaffold

Use this prompt to consistently plan and scaffold pytest test modules for selected Python source modules.

Supplied Inputs

  • target_modules: {{target_modules}}
  • mode: {{mode}}
  • path_strategy: {{path_strategy}}
  • naming_style: {{naming_style}}

Inputs

  • Required:
  • target_modules: one or more module paths under src/
  • mode: one of plan-only or scaffold
  • Optional:
  • path_strategy: preference for how source paths map into tests/
  • naming_style: preference for concise method naming style

Required References

Load these in order and apply only the relevant sections:

  1. Primary conventions: Pytesting Skill
  2. Hierarchy and naming: Naming and Organization
  3. Marker and fixture defaults: Pytest Docs Notes

Workflow

  1. Inspect the current tests/ layout and infer existing naming and grouping conventions.
  2. Propose a concise hierarchy plan first:
  3. test file paths
  4. class hierarchy
  5. method naming pattern
  6. fixture placement choices (tests/conftest.py or subtree conftest.py)
  7. If mode is scaffold, implement only the scaffold structure:
  8. create missing test modules
  9. create class hierarchy
  10. add one-line docstrings to each class and test method
  11. keep test method names short and behavior-focused
  12. Treat docstring-only scaffolds as an intentionally stable baseline for later fill-in work.
  13. Validate collection with:
  14. uv run pytest --collect-only -q
  15. Report outcomes:
  16. files created or updated
  17. collection result
  18. ambiguities and follow-up choices

Naming Defaults

  • Class naming:
  • Test as a top-level subject class
  • nested Test classes where extra context improves readability
  • Test top-level classes for standalone module functions
  • Method naming:
  • test_
  • one behavior target per method
  • one-line docstring for full intent

Authoring Rules

  1. Keep scope focused on structure and naming in this prompt.
  2. Do not fill test implementation details unless explicitly requested.
  3. Preserve established repository conventions when they are already present.
  4. If input constraints conflict, ask one concise clarifying question before editing.

Output Contract

Return:

  1. Discovery summary and references used.
  2. Proposed or applied test tree.
  3. Class and method naming map.
  4. Validation command result.
  5. Open questions only when they block completion.