vm-tdd-template-generator
Skill detail with category, linked agents, and source metadata.
vm-tdd-template-generator
Generates failing test templates from requirements, user stories, or feature descriptions following Test-Driven Development (TDD) methodology. Produces language-specific test scaffolds (Python/pytest, TypeScript/Vitest, etc.) with proper naming conventions, Arrange-Act-Assert structure, and placeholder implementations. Supports unit, integration, and E2E/BDD test types with configurable test pyramid ratios.
Source: .github/skills/testing/vm-tdd-template-generator/SKILL.md
Used By Agents
Preview
View source preview (first 3000 chars)
# VM TDD Template Generator
## Overview
Given requirements, user stories, or feature descriptions, this skill generates **failing test templates** that follow TDD's Red-Green-Refactor cycle. Templates are language-specific, follow established naming conventions, and include structured placeholders for implementation.
This skill is generative: it interprets requirement semantics to produce test scaffolds. All generated tests are intentionally failing (Red phase) — implementation agents complete the Green phase.
## When to Use
- Before implementing any feature (TDD: tests first)
- When a Test Strategy Planner needs to generate concrete test files
- When language-specific developers receive requirements and need test scaffolds
- When an implementation coordinator needs to seed test infrastructure for a project
## When NOT to Use
- Tests already exist and need modification (use the agent directly)
- Exploratory or ad-hoc testing (no structured requirements to drive from)
- Test execution or validation (this skill generates templates only)
## Inputs
```json
{
"requirements": [
{
"id": "FR-001",
"text": "Requirement or user story text",
"type": "functional|non-functional|security|constraint",
"priority": "critical|high|medium|low",
"acceptance_criteria": ["AC1", "AC2"]
}
],
"language": "python|typescript",
"test_types": ["unit", "integration", "e2e"],
"framework_config": {
"test_framework": "pytest|vitest|jest",
"ui_framework": "react|vue|angular|none",
"api_framework": "fastapi|flask|django|express|nestjs|none"
},
"pyramid_ratios": {
"unit": 70,
"integration": 20,
"e2e": 10
},
"output_path": "tests/"
}
```
### Input Defaults
| Field | Default | Notes |
|-------|---------|-------|
| `language` | Inferred from project | Scan for `pyproject.toml`, `package.json`, etc. |
| `framework_config.test_framework` | `pytest` (Python), `vitest` (TypeScript) | Based on language. Must be compatible: Python supports `pytest`; TypeScript supports `vitest` or `jest`. Invalid combinations (e.g., `python` + `jest`) will return an error. |
| `pyramid_ratios` | `{unit: 70, integration: 20, e2e: 10}` | Standard test pyramid |
| `test_types` | `["unit", "integration"]` | E2E only when explicitly requested |
## Method
### Step 1: Requirement Analysis
For each requirement, decompose into testable scenarios:
1. **Happy path** — Primary success scenario
2. **Invalid input** — Malformed or missing data
3. **Edge cases** — Boundary values, empty collections, max limits
4. **Error handling** — Expected failure modes
5. **Security** (if applicable) — Authorization, injection, validation
Map each scenario to a test type based on pyramid ratios:
- Pure logic, transformations, calculations → **Unit**
- API endpoints, database operations, service interactions → **Integration**
- User flows, critical business paths → **E2E**
### Step 2: Test Naming Convention
Apply consistent naming:
**Py