AI에게 테스트 작성을 시키기 전에 관점 리스트를 전달하도록 했다

AI에게 "테스트를 작성해줘"라고 부탁하면, 정상계 (Happy Path) 테스트만 돌아오는 경우가 있습니다.

물론 정상계 테스트도 필요합니다. 하지만 버그를 줄이는 목적으로 테스트를 작성하고 있는데, invalid input (유효하지 않은 입력), 인가 (Authorization), 중복 실행, 에러 발생 시의 표시 등이 빠지게 되면, 나중에 사람이 관점을 다시 추가해야 하는 상황이 발생합니다.

이 기사에서는 AI에게 테스트 구현을 부탁하기 전에, 관점 리스트를 먼저 전달하는 운영 방식을 정리합니다.

테스트 의뢰 전에 다음 표를 채웁니다.

테스트 관점:
- 정상계: 대표적인 입력으로 기대 결과가 나온다
- 경계값 (Boundary Value): 0건, 1건, 상한 건수, 빈 문자열, null
...

그 후, 이번 대상에 불필요한 관점은 해당 없음이라고 명시합니다.

AI에게 "이 기능의 테스트를 추가해줘"라고 부탁하면, 다음과 같은 테스트가 되기 일쑤였습니다.

test("saves settings", async () => {
await saveSettings({ theme: "dark" });
expect(await loadSettings()).toEqual({ theme: "dark" });
...

이것은 필요한 테스트이지만, 이것만으로는 다음 케이스들을 볼 수 없습니다.

• 빈 설정을 전달하면 어떻게 되는가
• 깨진 JSON을 읽으면 어떻게 되는가
• 동일한 저장을 2회 실행했을 때 중복되지 않는가
• 로딩에 실패했을 때 사용자에게 무엇을 반환하는가
• 기존 설정과의 호환성은 유지되는가

사람이 나중에 "이 케이스도"라며 추가하게 되면, 테스트의 의도가 분산됩니다.

원인은 의뢰 문구가 "테스트를 작성한다"라는 작업명뿐이었기 때문입니다.

AI는 수중에 있는 코드에서 대표적인 happy path (행복 경로)를 찾아내는 데 능숙합니다. 반면, 사양으로서 명문화되지 않은 경계값이나 인가 조건은 의뢰 문구에 나타나지 않으면 우선순위가 낮아집니다.

그래서 구현 전에 테스트 관점을 전달하도록 했습니다.

처음에 넓은 범위의 관점을 전달합니다.

이번 테스트에서 보고 싶은 관점:
- 정상계
- 빈 데이터
...

이 시점에서는 아직 테스트 이름을 쓰게 하지 않습니다. 먼저 "어떤 관점이 필요한가"를 정리하게 합니다.

불필요한 관점은 삭제하는 것이 아니라, 해당 없음이라고 적습니다.

인가: 해당 없음. 로컬 전용 설정 저장으로 사용자 소유 데이터를 다루지 않음.
외부 API 실패: 해당 없음. 대상 처리는 네트워크를 타지 않음.
멱등성 (Idempotency): 동일한 설정 저장을 2회 실행해도 1건으로 취급함.

이를 통해 리뷰 시점에 "놓친 것인지, 의도적으로 제외한 것인지"를 알 수 있습니다.

테스트 이름은 "무엇을 하면 어떻게 되는가"까지 쓰게 합니다.

test("returns default settings when stored JSON is broken", async () => {
await writeRawSettings("{broken");
const settings = await loadSettings();
...

handles error라고만 적으면 무엇을 기대하고 있는지 읽을 수 없습니다. 테스트 이름에 결과까지 포함하면, 구현을 변경했을 때의 리뷰가 쉬워집니다.

관점 리스트를 전달하더라도 모든 것을 자동으로 테스트할 필요는 없습니다.

외부 API, DB, 브라우저, 시간 의존적 처리는 무리하게 무거운 통합 테스트 (Integration Test)로 몰아넣으면 유지보수 비용이 상승합니다. 단체 테스트 (Unit Test)로 보는 범위, 통합 테스트로 보는 범위, 수동 확인으로 남길 범위를 나눕니다.

또한, AI가 생성한 테스트는 동일한 AI에게 자기 채점을 시키는 것만으로는 불충분합니다. 적어도 실패 시의 메시지, 테스트 이름, fixture (피스처)의 현실성은 사람이나 별도의 에이전트 (Agent)가 재검토해야 합니다.

AI에게 테스트를 작성하게 하기 전에 관점 리스트를 전달함으로써, 정상계에만 치우치는 문제를 줄일 수 있었습니다.

• 작업명이 아니라 보고 싶은 관점을 먼저 전달한다
• 불필요한 관점은 해당 없음이라고 명시한다
• 테스트 이름에 기대 결과까지 넣는다
• 무거운 테스트에 너무 치우치지 않고 확인 범위를 나눈다

"테스트를 작성해줘"가 아니라 "이 관점을 만족하는 테스트를 작성해줘"라고 전달하는 것이 리뷰 가능한 결과물이 되었습니다.

• harness17/zenn-articles - 본 기사에서 다룬 기사 리포지토리
• AI에게 구현을 맡기기 전에 완성 조건을 선언하는 Sprint Contract 운영 - 완성 조건으로서 테스트 관점을 먼저 두는 관련 운영
• AI에게 "수정해줘"라고 부탁하면 무관한 코드까지 건드리는 문제를 Surgical Changes 규칙으로 억제함 - AI에 대한 사전 제약 관련 운영