test-driven-development

개요

이 스킬이 하는 일

test-driven-development 스킬은 엄격한 Test-Driven Development(TDD) 워크플로우를 규정합니다. 항상 프로덕션 코드를 작성하기 전에 실패하는 테스트를 먼저 만들고, 엄격한 Red-Green-Refactor 사이클을 적용하도록 유도합니다.

막연한 “언젠가 테스트도 쓰자” 수준의 가이드가 아니라, 다음과 같은 강력한 규칙을 제공합니다:

• 실패하는 테스트 없이 프로덕션 코드를 작성하지 않는다
• 테스트가 올바른 이유로 실패하는지 항상 확인한다
• 테스트를 통과시키는 데 필요한 최소한의 코드만 작성한다
• 모든 테스트가 초록(GREEN)이 된 후에 리팩터링한다

또한 깨지기 쉽고 잘못된 방향으로 이끄는 테스트를 피하도록 돕는 전용 testing-anti-patterns 가이드와 연결됩니다.

이런 분께 추천합니다

다음과 같은 경우라면 test-driven-development 스킬을 사용하는 것이 좋습니다:

• 기능 개발, 버그 수정, 리팩터링에 대해 신뢰할 수 있는 워크플로우를 원하는 개발자
• 팀 차원에서 TDD를 표준으로 삼고 모두가 따를 수 있는 명확한 규칙이 필요한 팀
• 일관된 테스트 자동화 습관을 정착시키고 싶은 코치 또는 테크 리드

이 스킬은 특히 JavaScript 및 TypeScript 코드베이스에서 유용하지만, 그 원칙은 언어와 테스트 프레임워크에 상관없이 적용할 수 있습니다.

이 스킬이 해결하는 문제

이 스킬은 일상적인 개발 과정에서 흔히 발생하는 다음과 같은 문제를 해결하도록 설계되었습니다:

• 코드를 먼저 작성하고, 나중에(혹은 아예) 테스트를 추가하는 방식
• 테스트가 실제로 동작을 제대로 검증하고 있는지 불명확한 경우
• 테스트가 약하거나 없어서 리팩터링이 두려운 상황
• 실제 동작 대신 가짜(mock) 동작만 검증하는 과도한 또는 잘못된 mock 사용

test-driven-development 워크플로우를 따르면 다음과 같은 효과를 얻을 수 있습니다:

• 실패하는 테스트를 통한 빠른 피드백
• 의도된 동작에 대한 명확한 기록 확보
• 테스트로 동작이 고정되어 있어 리팩터링을 더욱 안전하게 수행
• mock이나 구현 세부사항만 검증하는 취약한 테스트를 피할 수 있음

언제 사용해야 할까 (그리고 언제는 아닐까)

업스트림 스킬에서는 TDD 적용을 다음과 같은 경우에 명시적으로 권장합니다:

• 새로운 기능 개발
• 버그 수정
• 리팩터링 작업
• 어떠한 동작 변경이든

반면, 다음과 같은 예외 상황은 사람과 논의해 결정하도록 언급합니다:

• 곧 버릴 전제의 프로토타입
• 자동 생성 코드
• 설정(Configuration) 파일

단순히 “가볍게 탐색해 보는” 수준이거나, 곧 버릴 것을 전제로 한 짧은 spike라면, 이 엄격한 test-driven-development 스킬은 다소 무거울 수 있습니다. 하지만 프로덕션 기능 개발에서는 이 스킬이 선택 옵션이 아니라 기본 워크플로우가 되는 것을 목표로 합니다.

사용 방법

설치

obra/superpowers 저장소에서 test-driven-development 스킬을 설치하려면 다음 명령을 실행하세요:

npx skills add https://github.com/obra/superpowers --skill test-driven-development

이 명령은 test-driven-development 스킬 정의와 관련 지원 파일들을 Agent Skills 환경으로 가져옵니다. 설치 후에는 스킬의 파일을 열어 상세 규칙과 안티패턴 예제를 직접 확인할 수 있습니다.

이 스킬에서 참조하는 핵심 파일은 다음과 같습니다:

• SKILL.md – Iron Law 및 Red-Green-Refactor를 포함한 핵심 TDD 규칙
• testing-anti-patterns.md – 테스트에서 하면 안 되는 것에 집중한 가이드

핵심 원칙: Iron Law

이 스킬의 중심에는 소스에서 Iron Law라고 부르는 규칙이 있습니다:

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

실제로는 다음을 의미합니다:

• 테스트보다 먼저 프로덕션 코드를 작성했다면, 그 코드는 삭제하고 처음부터 다시 시작해야 합니다.
• 테스트를 작성하면서 참고용으로 남겨두거나 조금씩 수정하는 식으로 유지하지 않습니다.
• 테스트를 기반으로 다시 구현할 때, 삭제한 코드를 슬쩍 보면서 구현하지 않습니다.

이 강력한 규칙 덕분에 모든 프로덕션 코드 라인은 실제 테스트에 의해 주도되도록 보장됩니다.

단계별 TDD 워크플로우

test-driven-development 스킬을 설치한 뒤에는, 이를 기본 워크플로우로 적용해 보세요:

1. 실패하는 테스트 작성 (RED)

• 하나의 구체적인 동작(기능, 버그 수정, 리팩터링 결과)을 선택합니다.
• 그 동작을 표현하는 새로운 테스트를 작성합니다.
• 테스트를 실행하여 이 새 테스트가 실패하는지 확인합니다.

RED 단계는 다음을 모두 만족할 때까지 끝난 것이 아닙니다:

• 테스트가 실패하는 것을 직접 확인했는지
• 올바른 이유(올바른 assertion, 올바른 에러)로 의도한 방식대로 실패하는지 확인했는지

실패 이유가 엉뚱하다면(예: 테스트가 크래시나 잘못된 세팅 때문에 실패하는 경우), 테스트를 수정하고 다시 실행하여 의미 있는 방식으로 실패할 때까지 반복합니다.

2. 테스트를 통과시키는 최소 코드 작성 (GREEN)

• 실패한 테스트를 통과시키기 위해 필요한 가장 단순한 코드만 구현합니다.
• 성급한 설계, 과도한 추상화, 불필요한 로직 추가는 피합니다.
• 테스트 스위트를 실행하여 새 테스트가 초록(GREEN) 상태가 되었고 기존 테스트도 모두 통과하는지 확인합니다.

이 단계에 대한 스킬의 가이드는 의도적으로 범위를 좁게 잡습니다. 지금의 목표는 “기능을 완성하는 것”이 아니라, 테스트를 만족시키는 것입니다.

3. 안전하게 리팩터링 (REFACTOR)

모든 테스트가 초록이 되면:

• 프로덕션 코드를 정리합니다: 중복 제거, 로직 단순화, 이름 개선 등
• 테스트 코드도 정리합니다: 가독성을 높이고, 필요하다면 helper를 추출합니다.
• 동작이 변하지 않았는지 확인하기 위해 테스트를 자주 실행합니다.

이 과정은 테스트 스위트에 의해 동작이 보장된 상태에서 설계를 개선하도록 도와줍니다.

4. 이 사이클 반복

작은 동작이나 엣지 케이스마다 다음을 반복합니다:

• 새로운 테스트 추가 (RED)
• 테스트를 통과시키는 코드 작성 (GREEN)
• 필요 시 리팩터링 (REFACTOR)

test-driven-development 스킬은 여러분이 이 루프 안에 머물도록 돕고, 단계를 건너뛰고 싶은 유혹을 줄이는 역할을 합니다.

기존 스택과의 통합

저장소 예제는 JavaScript와 TypeScript에 초점을 맞추고 있지만, TDD 규칙 자체는 스택과 무관하게 적용할 수 있습니다:

• JavaScript/TypeScript 프로젝트(Jest, Vitest, Mocha 등 사용)에서는:

  • 프로덕션 파일을 수정하기 전에 항상 테스트(*.test.ts, *.spec.ts 등)를 만들거나 수정합니다.
  • 애플리케이션 코드의 모든 변경에 대해 Red-Green-Refactor 사이클을 적용합니다.

• 그 외 언어(Python, Java, Go, C# 등)에서는:

  • 사용하는 테스트 프레임워크(pytest, JUnit, Go test, xUnit 등)에 맞게 동일한 단계를 매핑합니다.
  • “실패하는 테스트 없이 프로덕션 코드를 작성하지 않는다”는 엄격한 규칙은 그대로 유지됩니다.

이 스킬 자체는 특정 프레임워크를 강제하지 않습니다. 워크플로우 규칙을 정의하는 것이지, 라이브러리 의존성을 강제하는 것이 아닙니다.

testing anti-patterns 가이드 활용하기

같이 제공되는 testing-anti-patterns.md 파일은 test-driven-development 스킬의 보조 가이드 역할을 합니다. 다음과 같은 상황에서 불러오거나 참고하세요:

• 새로운 테스트를 작성하거나 기존 테스트를 수정할 때
• mocks나 stubs를 추가할 때
• 프로덕션 클래스나 모듈에 테스트 전용 hook을 추가하고 싶은 유혹이 들 때

이 가이드에서 강조하는 핵심 원칙은 다음과 같습니다:

• mock 동작 자체를 테스트하지 않는다 – 테스트는 mock이 존재한다는 사실이 아니라, 실제 동작을 검증해야 합니다.
• 프로덕션 클래스에 테스트 전용 메서드를 추가하지 않는다 – 프로덕션 API는 깔끔하게 유지해야 합니다.
• 의존성을 이해하지 못한 상태에서 mock을 남발하지 않는다 – 과도한 mocking은 잘못된 자신감을 낳습니다.

안티패턴 예제는 TypeScript 스타일의 테스트를 사용하여 나쁜 테스트와 좋은 테스트를 비교합니다. 사용하는 테스트 프레임워크에 맞게 쉽게 응용할 수 있습니다.

팀에 맞게 워크플로우 조정하기

설치 후에는 test-driven-development 스킬의 규칙을 팀 현실에 맞게 조정하되, 핵심 의도는 유지하는 것이 좋습니다:

• 어떤 종류의 변경이 반드시 엄격한 TDD를 따라야 하는지(예: 모든 프로덕션 모듈, 도메인 로직, 핵심 플로우 등)를 팀에서 합의합니다.
• 예외로 허용할 수 있는 케이스(예: 짧은 spike나 생성 코드 등)를 정하되, 이를 명시적으로 관리합니다.
• 코드 리뷰 체크리스트에 Iron Law를 포함시킵니다:
  • “이 변경을 이끈 실패하는 테스트는 어디에 있나요?”
  • “테스트가 먼저 작성되었나요?”

이렇게 하면 이 스킬을 개인 습관을 넘어, 팀 표준으로 활용할 수 있습니다.

자주 묻는 질문(FAQ)

test-driven-development 스킬은 특정 테스트 프레임워크 전용인가요?

아니요. test-driven-development 스킬은 특정 테스트 프레임워크가 아니라 워크플로우와 규칙을 정의합니다. 저장소 예제는 JavaScript와 TypeScript를 중심으로 되어 있지만, Red-Green-Refactor 루프 자체는 어떤 언어에서도 그대로 적용할 수 있습니다.

테스트 없이 작성한 코드는 정말 삭제해야 하나요?

SKILL.md에 정의된 Iron Law에 따르면 그렇습니다. 실패하는 테스트보다 먼저 프로덕션 코드를 작성했다면, 그 코드는 삭제하고 테스트부터 다시 시작해야 합니다. 이는 테스트를 사후에 덧붙이는 요소로 취급하려는 유혹을 제거하기 위한 규칙입니다.

이 스킬이 맞지 않는 경우도 있나요?

업스트림 가이드에서는 곧 폐기할 프로토타입, 자동 생성 코드, 설정 파일 등 몇 가지 잠재적 예외를 제시합니다. 수명이 짧은 실험적 spike에서는 엄격한 test-driven-development가 과할 수 있습니다. 반대로 프로덕션 기능, 버그 수정, 리팩터링 작업에는 이 스킬이 기본값으로 쓰이도록 설계되었습니다.

이 스킬이 디버깅과 리팩터링에는 어떻게 도움이 되나요?

버그를 고치거나 리팩터링을 할 때는 다음과 같이 활용합니다:

• 먼저, 버그를 재현하거나 의도한 동작을 설명하는 실패하는 테스트를 작성합니다.
• 그다음, 이 테스트가 통과할 때까지 코드를 수정합니다.
• 마지막으로, 테스트가 동작을 보증해 주므로, 보다 안심하고 리팩터링을 진행할 수 있습니다.

이 방식은 디버깅을 더 체계적으로 만들고, 리팩터링의 안전성을 높여줍니다.

기존에 테스트가 없는 레거시 코드에도 사용할 수 있나요?

네. 다만 점진적으로 적용하게 될 가능성이 큽니다:

• 레거시 코드를 수정해야 할 때, 먼저 현재 또는 원하는 동작을 캡처하는 테스트를 추가합니다.
• (동작을 변경하는 경우) 이 테스트가 실패하는 것을 본 다음, 테스트가 통과하도록 코드를 수정합니다.
• Red-Green-Refactor 루프를 이용해 해당 영역을 조금씩 테스트 범위 안으로 끌어옵니다.

시간이 지나면서 더 많은 레거시 코드가 테스트로 보호받게 됩니다.

설치 후에는 무엇부터 시작해야 하나요?

설치 명령을 실행한 뒤에는 다음 파일부터 살펴보세요:

• SKILL.md: test-driven-development 핵심 규칙과 Red-Green-Refactor 설명
• testing-anti-patterns.md: 테스트 작성 시 피해야 할 대표적인 실수들

이 두 파일을 일상적인 개발 워크플로우의 기준점으로 삼으면 좋습니다.