test-driven-development

test-driven-development 스킬 개요

test-driven-development 스킬은 먼저 동작을 테스트로 입증한 뒤, 그 테스트를 통과시키는 가장 작은 수정만 적용하도록 도와줍니다. “대충 맞아 보이는” 수준으로는 부족한 로직 변경, 버그 수정, 엣지 케이스 처리, 회귀(regression) 대응 작업을 하는 개발자와 에이전트에 특히 잘 맞습니다. 추측을 줄이기 위해 test-driven-development 스킬을 도입하려는 경우, 이 가이드는 언제 적합한지와 실제로 무엇이 좋아지는지를 설명합니다. 즉, 더 안전한 수정, 더 명확한 요구사항, 그리고 첫 패치 이후의 불필요한 되돌림 감소입니다.

이 스킬이 필요한 상황

test-driven-development는 작업이 실제 동작을 바꾸는 경우에 쓰는 것이 좋습니다. 예를 들어 새 함수 추가, 조건 변경, 버그 재현, 혹은 기존 코드를 조용히 망가뜨릴 수 있는 모든 변경이 여기에 해당합니다. 특히 저장소에 이미 테스트가 있고, 에이전트가 임의로 동작을 만들어내는 대신 프로젝트의 기존 검증 체계 안에서 작업하길 원할 때 유용합니다.

무엇이 다른가

핵심 가치는 규율에 있습니다. 먼저 실패하는 테스트를 작성하고, 그 테스트가 증명하는 범위 안에서만 구현을 추가합니다. 이렇게 하면 에이전트가 노려야 할 목표가 분명해지고, 빠진 가정을 초기에 드러낼 수 있으며, 수정 범위도 좁게 유지하기 쉽습니다. test-driven-development for Skill Testing 관점에서는, 그럴듯한 패치와 실제로 검증된 패치의 차이를 만들어내는 경우가 많습니다.

잘 맞지 않는 경우

실행 시점의 동작 변화가 없는 수정에는 이 스킬을 쓰지 않는 편이 좋습니다. 예를 들어 문구 수정, 정적 콘텐츠 업데이트, 순수 설정 변경 같은 작업입니다. 프로젝트에 테스트 커버리지가 거의 없거나 아예 없다면 이 스킬이 전혀 쓸모없는 것은 아니지만, 테스트 하네스 자체를 먼저 세팅해야 할 수 있어 효과를 보기까지 시간이 더 걸립니다.

test-driven-development 스킬 사용 방법

스킬 설치 후 먼저 확인할 것

test-driven-development install이 필요하다면 저장소 설치 흐름은 다음과 같습니다:

npx skills add addyosmani/agent-skills --skill test-driven-development

설치 후에는 SKILL.md부터 읽으세요. 이 저장소에는 참고할 rules/, resources/, scripts/ 폴더가 따로 없으므로, 핵심은 스킬 파일을 꼼꼼히 읽고 그 지침을 현재 코드베이스에 어떻게 대응시킬지 파악하는 것입니다.

모호한 요청을 테스트 가능한 프롬프트로 바꾸기

좋은 test-driven-development usage는 “어떻게 구현할지”가 아니라 “어떤 동작을 보여야 하는지”에서 시작합니다. 좋은 입력 예시는 다음과 같습니다. “빈 이메일 검증에 대한 실패 테스트를 먼저 추가하고, 그다음 src/auth.ts에 최소 수정만 적용해.” 반대로 “로그인을 더 좋게 만들어” 같은 요청은 약합니다. 관찰 가능한 결과, 알고 있다면 대상 파일이나 모듈, 그리고 특히 신경 쓰는 회귀 위험을 함께 적어주세요.

RED-GREEN-REFACTOR 루프 따르기

이 스킬은 워크플로로 써야 효과가 큽니다. 먼저 현재 코드에서 실패하는 테스트를 작성하고(RED), 그 테스트를 통과시키는 최소한의 코드 변경을 적용한 뒤(GREEN), 테스트가 계속 통과하는 범위에서만 리팩터링합니다(REFACTOR). 실패를 재현하기 어렵다면 구현을 건드리기 전에 멈추고 테스트 케이스를 더 날카롭게 다듬으세요. test-driven-development는 실패 사례가 버그를 입증할 만큼 구체적일 때 가장 잘 작동합니다.

먼저 읽어야 할 파일

이 저장소에서는 가장 먼저 읽어야 할 파일이 SKILL.md입니다. 그다음에는 실제 작업 대상 프로젝트의 테스트 구성을 확인하세요. 테스트 러너 설정, 기존 테스트 관례, 그리고 바꾸려는 코드 주변의 인접 테스트가 우선입니다. 프로젝트에 이미 강한 패턴이 있다면 그대로 정확히 따르는 것이 좋고, 그렇지 않다면 테스트를 최소한으로 유지하되 무엇을 증명하는지 명확하게 드러나게 작성하세요.

test-driven-development 스킬 FAQ

이건 숙련된 엔지니어만 쓰는 건가요?

아니요. 초보자도 test-driven-development를 사용할 수 있습니다. 다만 시작점이 분명해야 합니다. 하나의 동작, 하나의 실패 테스트, 하나의 최소 수정처럼 범위를 좁히는 것이 중요합니다. 이 스킬은 넓은 기능 개발보다 작은 버그 수정에서 더 배우기 쉽습니다.

일반 프롬프트와 무엇이 다른가요?

일반 프롬프트는 “작동하는 코드”를 요구할 수 있습니다. 하지만 이 스킬은 “증거”를 요구합니다. test-driven-development guide는 성공 기준을 통과한 테스트로 정의하게 만들기 때문에, 모호성이 줄고 리뷰도 쉬워집니다.

언제 선택하지 말아야 하나요?

문서 작업, 포맷팅, 혹은 실행 시 동작으로 표현할 수 없는 변경에는 건너뛰세요. 또한 프로젝트에 쓸 만한 테스트 하네스가 전혀 없고, 필요한 작업도 빠른 비동작성 수정에 불과하다면 이 스킬은 우선순위가 아닙니다.

모든 생태계에 맞나요?

원칙적으로는 그렇습니다. 다만 실제 테스트 명령, assertion 방식, 파일 구조는 사용하는 스택에 따라 달라집니다. 이 스킬 자체는 프레임워크에 종속되지 않으며, Jest, Vitest, pytest, JUnit 또는 다른 러너 중 무엇을 쓸지는 로컬 저장소의 관례가 결정합니다.

test-driven-development 스킬 개선 방법

에이전트에 더 선명한 실패 사례를 주기

가장 좋은 입력은 실패하는 동작, 기대 결과, 경계 조건을 함께 명시합니다. 예: “parseDate("")를 실행하면 InvalidDateError를 던져야 한다. 먼저 테스트를 추가하고, 그다음 parser에 최소 패치를 적용해.” 이런 식의 요청은 test-driven-development 스킬이 구현을 막연히 추측하는 일을 줄여줍니다.

기존 테스트 스타일을 함께 알려주기

근처의 테스트 파일, 네이밍 패턴, 프로젝트에서 이미 쓰는 helper나 fixture를 함께 언급하세요. 저장소가 table-driven tests, mocks, integration tests 중 어떤 방식을 비슷한 동작에 쓰는지도 알려주면 좋습니다. 로컬 관례에 맞추면 신뢰도가 올라가고, 결과물도 병합 가능한 형태로 유지하기 쉽습니다.

흔한 실패 패턴을 경계하기

가장 큰 실수는 테스트보다 구현을 먼저 쓰는 것, 이미 통과하는 테스트를 쓰는 것, 그리고 실패 사례를 넘어 수정 범위를 과하게 넓히는 것입니다. 첫 출력이 너무 광범위하다면, 가능한 한 가장 작은 실패 테스트 하나와 최소 패치 하나만 요청하세요. 보통 이것이 신뢰할 수 있는 test-driven-development usage로 가는 가장 빠른 길입니다.

추측이 아니라 증거를 기준으로 반복하기

첫 번째 시도가 끝난 뒤에는 다음 증거 지점을 요청하세요. 예를 들어 또 다른 엣지 케이스, 회귀 테스트 하나, 혹은 통과 중인 테스트를 유지하는 리팩터링이 될 수 있습니다. 버그가 미묘하다면, 변경 전/후 동작 요약과 추가할 정확한 테스트 이름까지 요청하세요. 그러면 워크플로가 가정이 아니라 관찰 가능한 동작을 기준으로 계속 유지됩니다.