레거시 코드 회귀 테스트 프롬프트: 현재 동작과 변경 의도 분리

레거시 코드 회귀 테스트를 만들 때 현재 출력과 바람직한 동작을 한꺼번에 바꾸면 무엇이 깨졌는지 알기 어렵습니다. 먼저 현재 관찰을 기록하는 특성화 테스트와 승인된 변경을 요구하는 테스트를 나누세요. 그다음 계산 순서나 경계 연산자를 살짝 바꿨을 때 관련 테스트가 실패하는지 확인합니다.

이 가이드는 문서가 부족한 코드를 수정하거나 리팩토링하기 전에 보호할 동작을 찾는 개발자를 위한 것입니다. 현재 버그를 영구적인 요구사항으로 굳히거나, 모든 함수를 모의 객체로 바꾼 뒤 통과했다고 만족하는 일을 피하는 데 초점을 둡니다.

준비 사항과 모델 적용 범위

Claude에 대상 소스, 직접 호출자, 알려진 입력과 출력, 테스트 환경을 텍스트로 제공하면 테스트 초안을 받을 수 있습니다. 저장소 접근과 테스트 실행 기능은 별개입니다. 실행 도구가 없으면 코드는 제안이며, 통과 여부는 사용자가 실제 환경에서 확인해야 합니다.

현재 출력의 근거가 실행 로그인지, 기존 테스트인지, 소스에서 추론한 값인지 표시하세요. 데이터베이스가 있다면 실제 운영 데이터 대신 테스트 전용 fixture를 준비합니다. 외부 결제처럼 실행하면 부작용이 있는 경계는 대체하되, 검증하려는 내부 계산과 연결은 남깁니다.

입력 예시: 할인 후 금액으로 배송비 결정

다음은 설명용 가상 JavaScript 모듈 src/quote-order.mjs입니다. 입력 계약은 0 이상의 정수 원화 금액이며, 잘못된 타입 검사는 별도의 입력 계층에서 처리한다고 가정합니다.

export function quoteOrder(subtotalWon, couponWon = 0) {
  const merchandiseWon = Math.max(0, subtotalWon - couponWon);
  const shippingWon = merchandiseWon >= 30000 ? 0 : 3000;
  return {
    merchandiseWon,
    shippingWon,
    totalWon: merchandiseWon + shippingWon,
  };
}

위 금액은 설명을 위해 코드와 명세로 계산한 값이며 실행 로그가 아닙니다. 실제 요청에서는 같은 칸에 관찰 자료의 출처도 적으세요. 정상 주문만 사용한다는 계약이 있으면 음수와 문자열을 무작정 넣는 테스트보다 배송비 경계와 계산 순서가 먼저입니다.

사용법

1. 공개 경계를 선택합니다. 이 예시에서는 계산을 조합한 quoteOrder를 호출해야 할인과 배송비의 순서를 함께 보호할 수 있습니다.
2. 기대값을 독립적으로 적습니다. 테스트 안에서 구현과 같은 식으로 기대 합계를 다시 계산하지 말고 명세와 사례에서 정한 금액을 사용합니다.
3. 원본에서 특성화 테스트를 실행합니다. 예상과 다르면 무조건 구현을 수정하지 말고 입력 조건, 관찰 기록, 정책을 먼저 대조합니다.
4. 대표 변이 한 가지를 격리해 확인합니다. 예를 들어 무료 배송의 >=를 >로 바꾸면 정확히 30,000원인 사례가 실패해야 합니다. 공유 작업의 다른 변경은 되돌리지 않습니다.
5. 변이를 제거한 뒤 원본을 재확인합니다. 이후 리팩토링에서 같은 사례를 유지하고 실제 장바구니 표시 값까지 확인합니다.

결과 예시: 설명용이며 실제 모델 실행 결과가 아닙니다

아래 코드는 위 가상 모듈을 대상으로 한 테스트 작성 예입니다. 독자의 저장소에서 실행한 결과가 아닙니다.

import test from 'node:test';
import assert from 'node:assert/strict';
import { quoteOrder } from '../src/quote-order.mjs';

test('할인 후 30000원인 주문은 무료 배송이다', () => {
  assert.deepEqual(quoteOrder(33000, 3000), {
    merchandiseWon: 30000,
    shippingWon: 0,
    totalWon: 30000,
  });
});

test('할인 후 기준 미만이면 배송비를 더한다', () => {
  assert.deepEqual(quoteOrder(32000, 3000), {
    merchandiseWon: 29000,
    shippingWon: 3000,
    totalWon: 32000,
  });
});

test('쿠폰을 생략하면 상품 금액을 그대로 사용한다', () => {
  assert.deepEqual(quoteOrder(12000), {
    merchandiseWon: 12000,
    shippingWon: 3000,
    totalWon: 15000,
  });
});

파일을 예시 경로에 작성하고 해당 Node.js 환경을 확인했다면 node --test tests/quote-order.test.mjs로 실행할 수 있습니다. 코드가 있다는 이유로 “테스트 3개 통과”라는 로그를 만들어 넣어서는 안 됩니다.

모든 변이가 살아남았다고 바로 테스트를 늘리지는 마세요. 먼저 변이가 유효 입력에서 다른 결과를 만드는지 확인해야 합니다. 동일한 동작을 만드는 변이나 실행 자체가 깨진 변이를 실제 회귀 검출력과 섞으면 결론이 흐려집니다.

실패와 검증 체크리스트

• 현재 관찰과 새 요구사항의 기대값을 구분했는가?
• 알려진 버그나 미정 정책을 승인된 동작처럼 고정하지 않았는가?
• 실제 계산과 데이터 전달을 테스트 안에서 다시 구현하지 않았는가?
• 외부 의존성을 대체해도 내부 연결이 검증되는가?
• 경계값에서 작은 동작 변이를 잡을 수 있는가?
• 구문·환경 오류를 변이 검출 성공으로 세지 않았는가?
• 실행 기록 없는 사례를 통과로 표시하지 않았는가?
• 자신이 만든 변이를 제거한 원본 상태가 확인되었는가?

후속 프롬프트

다음 실제 테스트 기록과 변이 결과를 검토해 주세요.
{{원본_테스트_기록}}
{{변이별_코드와_결과}}
실행 오류, 기대값 오류, 동작이 같은 변이, 검증 누락을 나누세요.
검증 누락에는 원래 계약을 보존하는 최소 추가 사례를 제시하세요.
테스트를 건너뛰거나 기대값을 현재 오류에 맞춰 바꾸지 마세요.

출처와 편집 판단의 범위

• Anthropic: Prompt engineering overview: 성공 기준과 검사 방법을 먼저 정의하는 원칙을 참고했습니다.
• Node.js: Test runner: node:test, 비동기 테스트 완료와 실패 판정 방식의 기본 사용 근거입니다.
• Stryker: Mutant states and metrics: 검출, 생존, 실행 오류 등 변이 결과를 구분하는 근거입니다.

주문 금액, 테스트 코드와 수동 변이 절차는 편집 예시입니다. 특정 도구의 실제 점수나 회귀 방지율을 측정한 글이 아닙니다. 원본 동작을 확인하고 작은 유효 변이가 실패하는지부터 검토하세요.