Skip to main content

test-driven-development

Enforce Test-Driven Development discipline. Write failing test first, then minimal code, then refactor. Use when writing production code or implementing features. Do not use for debugging, documentation, or configuration tasks.

Datos de origen

Repositorio
digi4care/opencode-mastery
Última actividad en el origen
21 de febrero de 2026 a las 09:55
Idioma detectado de SKILL.md
inglés
Estrellas
0
Forks
0

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Explorador de archivos
3 archivos

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
name
test-driven-development
description
Enforce Test-Driven Development discipline. Write failing test first, then minimal code, then refactor. Use when writing production code or implementing features. Do not use for debugging, documentation, or configuration tasks.
license
MIT
compatibility
opencode
metadata
{"author":"obra/superpowers (adapted)","version":"1.0.0"}
# Test Driven Development ## When to Use Me Use me when: - write production code - add feature - implement - TDD - new function - create endpoint - add method - implement this - write code for Do not use me for: - debug - investigate - analyze error - refactor without changing behavior - documentation - configuration - setup - explore - spike - general programming questions - installation or troubleshooting - framework-agnostic code help - bug investigation (use systematic-debugging first) ## Workflow 1. Identify behavior to implement 2. Write failing test (RED) - one behavior, clear name, real code 3. Verify test fails correctly - MANDATORY, never skip 4. Write minimal code to pass (GREEN) - simplest possible 5. Verify all tests pass - MANDATORY, check other tests too 6. Refactor while staying green (REFACTOR) - clean up only 7. Repeat for next behavior ## Error Handling - Code written before test exists: STOP, request deletion, restart with test - Test passes immediately: Verify test tests the right thing, not existing behavior - Multiple behaviors in one test: Ask to split into separate tests - Refactoring with failing tests: STOP, require green tests first - I'll test after: STOP, TDD requires test first - no exceptions - Keeping code as reference: STOP, delete means delete ## Tools The following tools are available to enforce TDD: - `check-test-exists` - Verify test file exists before writing implementation - `validate-tdd-cycle` - Check if TDD cycle was followed via git history - `analyze-git-order` - Analyze commit order to verify test-first approach Use these tools to validate TDD compliance automatically. ## Quick Tests Should trigger: - Create a new API endpoint - Add user authentication - Implement a new endpoint with tests first - Implement payment processing - Write a login function Should not trigger: - Debug this error - Investigate why tests fail - Refactor this function (no behavior change) - Update the documentation - Configure the server Functional: - Write test before implementing login feature - Follow TDD for new endpoint ## References - `references/workflow-playbook.mdx` - RED-GREEN-REFACTOR cycle details - `references/anti-patterns.mdx` - Testing anti-patterns to avoid ## The Iron Law ``` NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST ``` Write code before the test? Delete it. Start over. ## Verification Checklist Before marking work complete: - [ ] Every new function/method has a test - [ ] Watched each test fail before implementing - [ ] Each test failed for expected reason - [ ] Wrote minimal code to pass each test - [ ] All tests pass - [ ] No errors or warnings in output - [ ] Edge cases covered
Ver en GitHub