ВяткинАртём
102 lines
4.4 KiB
Markdown
102 lines
4.4 KiB
Markdown
---
|
|
name: autotest-writer
|
|
description: "Write autotests that match the project's existing test style, framework, fixtures, and conventions. Use when: user asks to write tests, generate autotests, cover code with tests, add unit tests, add integration tests, написать тесты, покрыть тестами, написать автотесты, сгенерировать тесты, добавить тесты. Discovers patterns from existing tests first. Uses MCP context7 for library docs when needed. Applies python-review skill rules for type annotations."
|
|
argument-hint: "File or function to cover with tests (e.g. src/auth.py or src/auth.py::login)"
|
|
---
|
|
|
|
# Autotest Writer
|
|
|
|
Discovers how the project writes tests, then generates autotests that look like they were written by the same developer.
|
|
|
|
## When to Use
|
|
|
|
- Cover a new function or module with tests
|
|
- Generate tests from a TestLink mini-test decomposition (pairs with `testlink-decompose`)
|
|
- Add missing edge-case or negative tests
|
|
- Scaffold a test file for a new module
|
|
|
|
## Procedure
|
|
|
|
### Step 1 — Understand What to Test
|
|
|
|
From the user's request, identify:
|
|
- **Target**: specific file, class, function, or mini-test ID (e.g. `КМД-1831-MT1`)
|
|
- **Scope**: unit / integration / end-to-end
|
|
- **Source**: existing code to read, or mini-test structure from `testlink-decompose`
|
|
|
|
If the target is a mini-test ID — treat its steps and expected results as the test specification.
|
|
If the target is a source file — read it fully before proceeding.
|
|
|
|
### Step 2 — Discover Project Test Patterns
|
|
|
|
Follow the full discovery process in
|
|
[references/discover-patterns.md](./references/discover-patterns.md).
|
|
|
|
Output a one-line summary before continuing:
|
|
> Detected: **{framework}** · fixtures via **{conftest/class/factory}** · assertions: **{assert/custom}** · async: **{yes/no}** · mocks: **{unittest.mock / pytest-mock / none}**
|
|
|
|
### Step 3 — Resolve Library Documentation (if needed)
|
|
|
|
When the code under test uses a third-party library AND the project has no existing tests covering it:
|
|
|
|
1. Call `mcp_io_github_ups_resolve-library-id` with the library name to get the context7 ID
|
|
2. Call `mcp_io_github_ups_get-library-docs` with that ID to retrieve relevant docs
|
|
3. Extract: how to instantiate, patch, or assert against the library's objects
|
|
4. If context7 returns nothing — read the library's source from `site-packages/` in the virtualenv
|
|
|
|
Do NOT fetch docs for libraries already exercised in existing project tests.
|
|
|
|
### Step 4 — Plan the Tests
|
|
|
|
Before writing code, output a test plan as a table:
|
|
|
|
| # | Test name | Scenario type | Target | Fixtures needed |
|
|
|---|-----------|--------------|--------|-----------------|
|
|
| 1 | `test_login_valid_credentials` | happy path | `auth.login()` | `db_session`, `user_factory` |
|
|
| 2 | `test_login_wrong_password` | negative | `auth.login()` | `db_session`, `user_factory` |
|
|
| 3 | `test_login_user_not_found` | negative | `auth.login()` | `db_session` |
|
|
|
|
Coverage target: at minimum cover happy path + all negative/edge cases visible in the source.
|
|
|
|
Ask: "Продолжить? Или изменить план?" — wait for confirmation before writing code if the plan has more than 5 tests.
|
|
For ≤ 5 tests, proceed immediately.
|
|
|
|
### Step 5 — Write the Tests
|
|
|
|
Follow all rules in [references/write-rules.md](./references/write-rules.md).
|
|
|
|
Key constraints (never violate):
|
|
- Match the exact file naming convention discovered in Step 2
|
|
- Use the same fixture sources (conftest.py / inline / factory) as existing tests
|
|
- Use the same assertion style (plain `assert` vs custom matchers)
|
|
- Use the same import order and grouping
|
|
- Use Python 3.13+ type annotations on all new functions
|
|
- Match async/sync style of the surrounding test suite
|
|
|
|
### Step 6 — Place the File
|
|
|
|
Determine the output path:
|
|
- If a parallel test file exists (e.g. `src/auth.py` → `tests/test_auth.py`) — append to it
|
|
- If no test file exists — create one at the location matching the project layout
|
|
- Never create a test file in the source tree unless that is the project's convention
|
|
|
|
Output the full file path before writing.
|
|
|
|
### Step 7 — Validate
|
|
|
|
After writing, run:
|
|
|
|
```bash
|
|
# Syntax and type check
|
|
mypy --strict <test_file>
|
|
|
|
# Lint
|
|
ruff check <test_file>
|
|
|
|
# Execute tests (dry run — collect only)
|
|
pytest --collect-only <test_file>
|
|
```
|
|
|
|
Fix any collection errors or mypy/ruff violations silently.
|
|
If tests actually run — report pass/fail counts.
|