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.

소스 정보

저장소
digi4care/opencode-mastery
최근 소스 활동
2026년 2월 21일 09:55
감지된 SKILL.md 언어
영어
스타
0
포크
0

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
3 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
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
GitHub에서 보기