원클릭으로 Manus에서 모든 스킬 실행

시작하기

test-driven-development

스타4

포크0

업데이트2026년 4월 18일 08:17

Use when implementing features/fixes. Iron law: ¬∃ production code without failing test.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

MonsieurBarti

MonsieurBarti/The-Forge-Flow-CC

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Test-Driven Development

When to Use

∀ features/fixes where TDD applies. Simple tasks may skip TDD.

HARD-GATE

¬∃ production_code without failing_test_first. If code ∃ before test -> DELETE IT ∧ start over. Sunk cost irrelevant — time gone regardless.

Cycle

RED(write 1 test -> run -> observe FAIL) -> GREEN(minimal code to pass) -> REFACTOR(structure, tests stay green)

RED

it('should validate email format', () => {
  const result = validateEmail('not-an-email');
  expect(isErr(result)).toBe(true);
});

Rules: 1 behavior/test | descriptive name | describe/it/expect (¬test()) | MUST run ∧ watch FAIL

∀ test: fails for right reason (missing feature ¬syntax error). GREEN before impl -> feature ∃ ∨ test wrong — investigate.

GREEN

export const validateEmail = (email: string): Result<string, Error> => {
  if (!email.includes('@')) return Err(new Error('Invalid email'));
  return Ok(email);
};

Only enough code to pass. No more.

REFACTOR

Improve structure, ¬change behavior, tests stay green.

Agent Routing (standard/complex)

Tester subagent writes failing .spec.ts -> commits
Domain subagent implements -> tests pass -> commits
Tester subagent verifies coverage ∧ edge cases

Sunk Cost Rule

Deleting hours of work to start test-first is correct. Time gone regardless. Starting over w/ proper TDD produces better code faster than retrofitting tests.

3-Fix Red Flag

3+ test fixes attempted -> question the design, ¬ the test. Test probably right; impl approach wrong.

Anti-Patterns

Pattern	Problem	Fix
Tests after impl	Never verified test catches failures	Write test first -> watch fail -> implement
Mock behavior testing	`expect(mock).toHaveBeenCalled()` tests mock, ¬code	Use ∈-memory adapters implementing real interface
Over-mocking	Mock everything, test nothing real	∈-memory adapters: real interface, ¬I/O
"Too simple for TDD"	Simple code is where hidden bugs live	Follow the cycle regardless

Gate (∀ must be true before DONE)

∀ tests failed before impl? 2. Suite passes? 3. Testing behavior ∨ mock? (mock -> stop) 4. Catches regression? (¬ -> rewrite)

Framework

Vitest: describe/it/expect/beforeEach/afterEach | ¬test() | colocated .spec.ts | globals: true

이 저장소의 다른 Skills

같은 저장소

commit-conventions

MonsieurBarti/The-Forge-Flow-CC

Use when making git commits. Conventional commit format and rules.

2026-05-014

security-review

MonsieurBarti/The-Forge-Flow-CC

Use when running security review on a diff/PR/file. Research-vs-Reporting discipline, three-tier confidence gate, attacker-controllable taxonomy.

2026-04-304

plannotator-usage

MonsieurBarti/The-Forge-Flow-CC

Use when invoking plannotator for approval review of generated .tff-cc milestone artifacts (plan, verification, spec).

2026-04-304

brainstorming

MonsieurBarti/The-Forge-Flow-CC

Use when starting design or discovery work. MUST use before any creative work.

2026-04-294

report-issue

MonsieurBarti/The-Forge-Flow-CC

Use when the user wants to report a bug, file an issue, or send feedback about tff-cc. Triggers on phrases like 'report issue', 'file a bug', 'tff-cc broke', 'something is wrong with tff-cc', 'open an issue', '/report-issue'.

2026-04-294

skill-authoring

MonsieurBarti/The-Forge-Flow-CC

Use when creating, refining, or composing skills. Evidence-driven pattern analysis.

2026-04-294

name	test-driven-development
description	Use when implementing features/fixes. Iron law: ¬∃ production code without failing test.

Test-Driven Development

When to Use

∀ features/fixes where TDD applies. Simple tasks may skip TDD.

HARD-GATE

¬∃ production_code without failing_test_first. If code ∃ before test -> DELETE IT ∧ start over. Sunk cost irrelevant — time gone regardless.

Cycle

RED(write 1 test -> run -> observe FAIL) -> GREEN(minimal code to pass) -> REFACTOR(structure, tests stay green)

RED

it('should validate email format', () => {
  const result = validateEmail('not-an-email');
  expect(isErr(result)).toBe(true);
});

Rules: 1 behavior/test | descriptive name | describe/it/expect (¬test()) | MUST run ∧ watch FAIL

∀ test: fails for right reason (missing feature ¬syntax error). GREEN before impl -> feature ∃ ∨ test wrong — investigate.

GREEN

export const validateEmail = (email: string): Result<string, Error> => {
  if (!email.includes('@')) return Err(new Error('Invalid email'));
  return Ok(email);
};

Only enough code to pass. No more.

REFACTOR

Improve structure, ¬change behavior, tests stay green.

Agent Routing (standard/complex)

Tester subagent writes failing .spec.ts -> commits
Domain subagent implements -> tests pass -> commits
Tester subagent verifies coverage ∧ edge cases

Sunk Cost Rule

Deleting hours of work to start test-first is correct. Time gone regardless. Starting over w/ proper TDD produces better code faster than retrofitting tests.

3-Fix Red Flag

3+ test fixes attempted -> question the design, ¬ the test. Test probably right; impl approach wrong.

Anti-Patterns

Pattern	Problem	Fix
Tests after impl	Never verified test catches failures	Write test first -> watch fail -> implement
Mock behavior testing	`expect(mock).toHaveBeenCalled()` tests mock, ¬code	Use ∈-memory adapters implementing real interface
Over-mocking	Mock everything, test nothing real	∈-memory adapters: real interface, ¬I/O
"Too simple for TDD"	Simple code is where hidden bugs live	Follow the cycle regardless

Gate (∀ must be true before DONE)

∀ tests failed before impl? 2. Suite passes? 3. Testing behavior ∨ mock? (mock -> stop) 4. Catches regression? (¬ -> rewrite)

Framework

Vitest: describe/it/expect/beforeEach/afterEach | ¬test() | colocated .spec.ts | globals: true