VIRIM Infotech
Your AI Assisted Product Developers

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.

Category: testing Used by 5 agents

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