Show GN: false-green-detector: 무의미한 테스트를 잡아내는 에이전트 스킬

SKILL.md 원문(computerphilosopher/agent-skills)의 앞부분(1–2단계)을 옮겼어요. 뒤쪽 단계는 다 읽지 못했어요.

목적

A test and its implementation can agree while both contradict the specification.

기대값이 명세에서 나왔는지, 테스트가 명세를 어기는 동작을 잡아내는지 검토하는 스킬이에요. 테스트와 구현이 서로 맞아도 둘 다 명세와 어긋날 수 있어요. 명세 기반 테스트 리뷰나 "버그가 있는데도 통과하는 테스트, 구현을 그대로 베낀 테스트를 찾아 달라"는 요청에 써요.

1. 명세에서 기대 동작 도출

요구사항과 API·기능 명세를 읽고 각 동작을 전제 조건 → 입력·행동 → 기대 결과로 적어요. 결과에는 반환값, 저장된 데이터, 상태 변화, 외부 시스템 요청이 포함돼요.

예: "재고가 충분하면 주문을 받고 수량을 빼고, 아니면 거절하고 재고를 그대로 둔다." 재고 3에서 2개 주문은 성공하고 1이 남아야 하고, 4개 주문은 실패하고 3이 남아야 해요. 테스트와 비교하기 전에 이걸 먼저 정해요.

2. 테스트가 실제로 검증하는 것과 비교

기대 결과마다 그걸 확인하는 assertion을 찾고 준비·실행 경로를 읽어요. "주소 변경 → 주문 → 결제" 테스트가 결제 성공만 본다면 새 주소가 쓰였는지 확인하는 assertion이 더 필요해요.

• 기대값의 출처: 할인 함수를 테스트가 그대로 불러 기대값을 계산하면, 함수가 10% 대신 20%를 깎아도 둘 다 8,000이 돼 통과해요. 명세가 "10,000원에서 10% 할인"이면 독립적으로 구한 9,000과 비교해요.
• 전제 조건: 만료 쿠폰 거절 테스트가 존재하지 않는 쿠폰 코드를 쓰면, 만료 검사를 지워도 통과해요. 다른 조건은 다 맞고 기간만 지난 쿠폰을 써요.
• 관찰 가능한 결과: 주소 변경 테스트가 성공 응답만 보면 저장을 건너뛰어도 통과해요. A를 B로 바꾸고 다시 읽어 B인지 확인해요. 처음부터 B였다면 구분이 안 돼요.
• 이전 상태와 순서: 새 배송지를 추가하면 기존 기본 배송지 표시를 지워야 한다면, 주소가 없는 고객만 테스트해서는 못 잡아요. A가 기본인 상태에서 B를 추가하고 B가 기본, A는 아님을 확인해요. 변경·재시도·만료 후 동작 흐름도 봐요.
• 입력 구분: 고객 A와 B의 주소가 같으면 엉뚱한 주소를 써도 통과해요. 주소를 다르게 줘요. 경계값도 확인해요(최대 5개면 4·5 허용, 6 거절).
• 테스트 더블 범위: 주문 판단 함수를 항상 "재고 부족"을 돌려주는 스텁으로 바꾸면 재고 비교 로직은 검증되지 않아요. 재고 조회 의존성이 1을 돌려주게 하고 실제 로직에 2개를 주문해 거절을 확인해요.

실패 경로의 정리 작업도 확인해요. 다운로드 취소가 진행 중 전송을 멈춰야 한다면 '취소됨' 응답만 볼 게 아니라 전송 경계의 테스트 더블이 취소 요청을 받았는지, 실제로 멈췄는지를 teardown 전에 확인해요.