test-driven-development

test-driven-development 스킬 개요

test-driven-development 스킬이 실제로 하는 일

test-driven-development 스킬은 기능 개발, 버그 수정, 동작 변경에 대해 AI 에이전트가 엄격한 TDD 흐름을 따르도록 만듭니다. 즉, 먼저 테스트를 작성하고, 그 테스트가 올바른 이유로 실패하는지 확인한 뒤, 통과에 필요한 최소한의 프로덕션 코드를 작성하고, 마지막으로 안전하게 리팩터링하게 합니다. 핵심 가치는 단순히 “테스트도 같이 써라”가 아니라, 실행 가능한 동작이 구현을 이끌도록 순서를 강제하는 데 있습니다.

이 스킬이 특히 잘 맞는 사용자

이 test-driven-development skill은 정확성이 중요한 실제 저장소 작업에 AI를 쓰는 개발자에게 잘 맞습니다. 예를 들면 앱 기능 추가, 서비스 로직 구현, 버그 수정, 리팩터링, 회귀 방지 같은 작업입니다. 특히 모델이 곧바로 구현부터 시작하지 못하게 하고, 더 작고 검증 가능한 단계로 작업하게 만들고 싶을 때 유용합니다.

실제로 해결하는 문제

대부분의 사용자가 test-driven-development를 설치하는 이유는, 일반적인 코딩 프롬프트가 먼저 코드를 만들고 테스트를 나중에 덧붙이는 식으로 흘러가기 쉽기 때문입니다. 이 스킬은 그 행동을 바꿉니다. 실패하는 테스트에 구현을 고정시키기 때문에, 에이전트의 결과물을 검토하기 쉬워지고 검증되지 않은 동작을 지어낼 가능성도 줄어듭니다.

일반적인 “테스트 작성” 프롬프트와 다른 점

차별점은 이 스킬의 “철칙”에 있습니다. 실패하는 테스트 없이는 프로덕션 코드를 쓰지 않는다는 점입니다. 이는 보통의 프롬프트보다 훨씬 엄격합니다. 또한 처음의 실패가 단순히 아무 빨간 결과가 아니라, 정말로 의도한 실패인지 확인하도록 강조합니다. 이 실무적인 안전장치는 얕은 TDD 요약에서 자주 빠지는 부분입니다.

설치 전에 알아둘 중요한 한계

이 스킬은 프레임워크별 테스트 툴킷이 아니라 프로세스 스킬입니다. 전체 테스트 아키텍처를 대신 설계해주지는 않으며, SKILL.md와 testing-anti-patterns.md 외에 헬퍼 스크립트나 풍부한 참고 자료를 제공하지도 않습니다. Jest, Pytest, JUnit, Playwright 설정을 깊이 있게 안내받아야 한다면, 이 스킬은 완전한 테스트 매뉴얼이라기보다 워크플로 레이어로 보는 편이 맞습니다.

test-driven-development 스킬 사용 방법

test-driven-development 스킬 설치

다음 명령으로 저장소에서 설치합니다.

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

환경이 로컬 스킬 검색을 지원한다면, 기능 작업을 시작하기 전에 스킬이 test-driven-development로 표시되고 에이전트에서 사용 가능 상태인지 확인하세요.

먼저 읽어야 할 파일

이 test-driven-development install 및 사용 흐름에서는 아래 파일부터 보는 것이 좋습니다.

• skills/test-driven-development/SKILL.md
• skills/test-driven-development/testing-anti-patterns.md

워크플로와 제약을 파악하려면 먼저 SKILL.md를 읽으세요. 작업에 mocks, 격리, UI 테스트가 포함되거나, 프로덕션 코드에 테스트 전용 seam을 넣고 싶어질 만한 상황이라면 다음으로 testing-anti-patterns.md를 읽는 것이 좋습니다.

이 스킬이 최소한으로 필요로 하는 입력

이 스킬은 다음 정보를 주었을 때 가장 잘 작동합니다.

• 추가할 기능, 수정할 버그, 바꿔야 할 동작
• 관련 파일 또는 모듈 경계
• 저장소에서 이미 사용 중인 테스트 프레임워크
• 사용자가 보게 될 동작 또는 시스템 차원의 기대 동작
• API 형태, 하위 호환성, 성능 관련 제약

이 맥락이 없으면 에이전트가 기계적으로 TDD를 적용할 수는 있어도, 테스트 레벨을 잘못 고르거나 코드베이스보다 도구에 맞춘 어색한 테스트를 만들 수 있습니다.

대략적인 요청을 TDD-ready 프롬프트로 바꾸기

약한 프롬프트:

Add support for password reset.

더 강한 프롬프트:

Use the test-driven-development skill. We need password reset in the existing Node/Express app. Write the first failing integration or service-level test before any production code. Verify the failure is for missing reset behavior, not setup issues. Then implement the minimum code to pass. Keep the current route style, use Jest, and avoid changing unrelated auth flows.

이처럼 더 강한 버전은 에이전트가 올바른 첫 테스트를 고르고, red-green-refactor 사이클을 지키는 데 필요한 맥락을 제공합니다.

한 번에 크게 생성하지 말고, 단계별 워크플로로 사용하기

실무에서 유용한 test-driven-development usage 패턴은 다음과 같습니다.

1. 첫 번째 실패 테스트만 요청합니다.
2. 그 실패가 의도한 동작을 정확히 겨냥하는지 검토합니다.
3. 통과에 필요한 최소 구현만 요청합니다.
4. green 상태가 된 뒤에만 리팩터링을 요청합니다.
5. 다음 작은 동작 조각에 대해 반복합니다.

이 스킬은 작고 검증된 증분을 전제로 설계되어 있으므로, 한 번에 전체 기능을 달라고 하는 것보다 이런 방식이 훨씬 좋은 결과를 냅니다.

“red” 단계를 제대로 검증하기

이 test-driven-development guide에서 중요한 포인트는, 테스트가 실패했다는 사실만으로는 충분하지 않다는 점입니다. 그 실패는 테스트가 정확히 빠진 동작을 겨냥하고 있음을 보여줘야 합니다. import 오류, 깨진 fixture, 무관한 설정 문제 때문에 실패했다면 아직 사이클이 제대로 시작된 것이 아닙니다.

프롬프트에서 에이전트에게 왜 이 테스트가 실패하는지, 그리고 왜 그 실패가 올바른 실패인지 명시적으로 설명하라고 요구하세요.

올바른 첫 테스트 고르기

가장 좋은 첫 테스트는 보통 외부에서 의미 있게 관찰 가능한 가장 작은 동작 변화를 겨냥합니다. 좋은 후보는 다음과 같습니다.

• 버그 재현 하나
• 비즈니스 규칙 하나
• 엔드포인트 응답 변경 하나
• 도메인 메서드 동작 하나
• 사용자 영향이 분명한 UI 상호작용 하나

반대로, 거대한 end-to-end 시나리오, 광범위한 snapshot 커버리지, 내부 구현을 너무 일찍 고정해버리는 테스트는 시작점으로 좋지 않습니다.

mocks가 등장하면 anti-pattern 가이드를 적용하기

에이전트가 mocks를 과도하게 쓰기 시작한다면 testing-anti-patterns.md가 특히 중요해집니다. 이 스킬은 실제 동작 대신 mock 동작을 테스트하는 것을 강하게 경고합니다. 이는 특히 test-driven-development for Test Automation 맥락에서 중요합니다. AI 에이전트는 실제 출력보다 충족시키기 쉬운 mock placeholder에 대한 assertion을 만들기 쉽기 때문입니다.

테스트가 mock이 렌더링되었는지, mock이 사소한 방식으로 호출되었는지, 또는 테스트를 위해 프로덕션 코드에 메서드를 추가해야 하는지를 검증하고 있다면, 멈추고 테스트 범위를 다시 잡아야 합니다.

에이전트가 철칙을 지키게 하기

모델이 이미 구현 초안을 써버렸다면, 이 스킬의 가이드는 분명합니다. 프로덕션 코드를 지우고 실패 테스트부터 다시 시작해야 합니다. 실무에서 꼭 극적으로 대응할 필요는 없지만, 이전의 추측성 구현은 무시하고 test-first 순서로 다시 생성하라고 지시하는 것이 좋습니다.

쓸 만한 표현:

Do not continue from implementation-first code. Restart with a failing test and derive the implementation from that test.

저장소의 테스트 스택에 맞게 스킬 맞추기

이 스킬은 프로세스 중심이므로, 반드시 현재 스택에 연결해서 써야 합니다.

• Python 서비스라면 pytest
• JS/TS 로직이라면 Jest 또는 Vitest
• Ruby라면 RSpec
• Java라면 JUnit
• 브라우저 레벨 동작이어야 할 때만 Playwright 또는 유사 도구

저장소에 이미 견고한 테스트 피라미드가 있다면, 이번 변경이 어디에 속하는지 에이전트에게 알려주세요. 그렇지 않으면 모델은 가장 적절한 테스트보다 가장 눈에 띄는 테스트 스타일을 기본값으로 택할 수 있습니다.

실제 저장소 작업을 위한 예시 프롬프트

탄탄한 test-driven-development skill 프롬프트는 다음과 같습니다.

Use the test-driven-development skill for a bug fix. In billing/invoice_service.py, invoices with zero-amount adjustments should remain payable if tax is still due. Start by writing the smallest failing pytest that reproduces the current bug. Confirm the failure is caused by the missing business rule, not fixture issues. Then implement the minimum fix, run or describe the expected green result, and suggest any safe refactor only after the test passes.

이 프롬프트는 동작, 위치, 프레임워크, 검토 기준을 모두 제공합니다.

test-driven-development 스킬 FAQ

이미 TDD를 알아도 test-driven-development를 설치할 가치가 있나요?

그렇습니다. 문제의 핵심이 AI 에이전트가 TDD를 “설명만” 하고 실제로는 따르지 않는 데 있다면 특히 그렇습니다. test-driven-development skill은 교육 자료라기보다 모델의 행동을 제약하는 장치로서 가치가 큽니다.

초보자도 쓰기 쉬운가요?

대체로 그렇습니다. 워크플로 자체는 단순하고 명확합니다. 초보자에게 더 어려운 부분은 올바른 첫 테스트와 적절한 테스트 레벨을 고르는 일입니다. 테스트가 아직 익숙하지 않다면, 넓은 신규 기능보다 작은 버그 수정부터 이 스킬을 적용해보는 것이 좋습니다.

어떤 경우에 test-driven-development가 잘 맞지 않나요?

버리기 위한 프로토타입, 생성 코드, 순수 설정 변경에는 상대적으로 잘 맞지 않습니다. 다만 정확성 리스크가 크고 사람 리뷰어도 test-first 규율을 원한다면 예외가 될 수 있습니다. 원문 가이드도 이런 경우를 사람과 상의할 예외로 명시적으로 다룹니다.

일반적인 프롬프팅과는 어떻게 다른가요?

일반적인 프롬프트는 “X를 구현하고 테스트도 추가해”라고 말하는 경우가 많습니다. 이 스킬은 작업 순서를 바꾸고, 그 순서를 협상 불가로 다룹니다. 바로 그 순서 강제가 핵심 가치이며, 구현 환각을 줄이고 검토 가능성을 높여줍니다.

이 스킬이 프레임워크 설정까지 다루나요?

깊게 다루지는 않습니다. test-driven-development install 자체는 간단하지만, 스킬 내부에 프레임워크별 설정 문서가 풍부하게 들어 있지는 않습니다. 기존 테스트 스택이나 저장소 관례를 사용자가 에이전트에게 지정해줄 수 있다는 전제를 둡니다.

리팩터링에도 test-driven-development를 쓸 수 있나요?

네. 동작을 안정적으로 유지해야 하는 리팩터링에 잘 맞습니다. 실전 패턴은 먼저 현재 동작을 테스트로 고정한 다음, green 테스트를 안전망으로 삼아 리팩터링하는 것입니다.

UI 및 end-to-end 테스트에도 좋은가요?

경우에 따라 그렇지만 주의가 필요합니다. UI 작업에서는 anti-pattern 파일이 특히 중요합니다. AI가 mock 존재 여부나 구현 흔적에 대한 assertion으로 미끄러지기 쉽기 때문입니다. 검증 가능한 가장 작은 실제 사용자 동작부터 시작하세요.

test-driven-development 스킬 개선 방법

해결책 아이디어보다 동작을 설명하기

더 나은 test-driven-development usage를 원한다면, 구현 방식을 지시하기보다 기대 동작과 제약을 설명하세요. TDD는 테스트가 결과를 정의하고, 코드는 그 검증에서 자연스럽게 나오도록 둘 때 가장 잘 작동합니다.

더 좋은 입력:
Users should see an error when uploading files over 10MB.

덜 좋은 입력:
Add a fileSizeValidator class and call it from the controller.

첫 번째 방식이 더 깔끔하고 최소한의 구현이 나올 여지를 남겨둡니다.

원하는 테스트 레벨을 명시하기

약한 결과의 상당수는 테스트 범위가 어긋나서 나옵니다. 에이전트에게 다음 중 무엇을 원하는지 분명히 말하세요.

• unit-level 비즈니스 로직
• 서비스나 API 주변의 integration
• 브라우저 레벨 동작

이 한 가지 선택이 다른 어떤 프롬프트 디테일보다 더 중요하게 작용하는 경우가 많습니다.

더 작은 증분을 강제하기

흔한 실패 패턴 중 하나는 한 사이클에 너무 많은 것을 요구하는 것입니다. 모델이 넓은 테스트 스위트와 큰 구현을 한꺼번에 써버린다면, 범위를 줄이세요.

Pick one failing test that captures the first slice of behavior. Do not implement the whole feature yet.

이렇게 해야 test-driven-development 루프가 무너지지 않습니다.

첫 테스트가 왜 맞는지 설명하게 하기

에이전트에게 다음을 정당화하라고 요구하세요.

• 왜 이 테스트가 가장 작은 유의미한 조각인지
• 정확히 어떤 실패가 예상되는지
• 왜 그 실패가 해당 동작의 부재를 증명하는지

이 과정을 넣으면 구현에 들어가기 전에 숨은 가정이 드러나므로 품질이 좋아집니다.

anti-pattern을 초기에 감시하기

가장 흔한 품질 저하는 다음과 같습니다.

• 동작 대신 mocks를 테스트함
• 프로덕션 코드에 테스트 전용 메서드를 도입함
• 처음부터 통과하는 테스트를 써놓고 TDD라고 부름
• 구현 세부사항에 묶인 assertion을 고름
• green이 된 뒤 리팩터링 단계를 건너뜀

이 중 하나라도 보이면, 주변을 덧대어 고치려 하지 말고 사이클을 멈춘 뒤 올바른 첫 테스트로 다시 잡아달라고 요청하세요.

저장소 관례를 구체적으로 제공하기

이 스킬은 다음 정보를 알려줄수록 더 좋아집니다.

• 테스트 네이밍 규칙
• 테스트 파일 위치
• fixture 패턴
• mocking 정책
• 선호하는 assertion 스타일

저장소가 제공하는 지원 자료가 가벼운 편이기 때문에, 이런 로컬 관례가 결과 품질에 실제로 큰 영향을 줍니다.

첫 결과 이후에는 반복적으로 다듬기

초기 결과를 받은 뒤 “더 해줘”라고만 하지 마세요. 대신 목표가 분명한 후속 질문을 던지세요.

• Can you make the failing test narrower?
• Is this failure due to setup or missing behavior?
• Can we remove this mock and test real behavior instead?
• What is the minimum code needed to pass?
• What refactor is now safe with tests green?

실무에서 test-driven-development skill의 효과를 가장 크게 높이는 방법은 이것입니다. 에이전트가 앞질러 가게 두지 말고, 계속 사이클 안에 머물게 하세요.

예외 상황에서는 사람의 판단과 함께 쓰기

이 스킬은 의도적으로 엄격합니다. 그 점이 강점이지만, 과하게 적용될 수도 있습니다. 작업이 순수 설정 변경, 생성 코드 갱신, 일회성 프로토타입이라면 완전한 TDD가 비용 대비 맞는지 먼저 따져보세요. 더 좋은 결과는 어디에나 적용하는 데서가 아니라, test-first 순서가 실제로 의사결정의 질을 바꾸는 작업에 쓰는 데서 나옵니다.