Regression Test
회귀 테스트
회귀 테스트는 나중에 코드가 바뀌어서 예전에 잘 되던 기능이 망가지지 않았는지 확인해요.
다른 예시
예전에는 다시 시도할 때 중복 결제가 발생했어요. 새 테스트는 결제 키를 반복 사용하고 딱 한 번만 결제되는지 확인해요.
주요 부분
- 01Code or behavior under test
- 02Observable evidence
- 03Coverage, failure, and recovery
사용할 때
반복되는 버그, 확실한 계약, 핵심 흐름, 또는 다시 실패할 수 있는 예외 케이스를 위해 하나 추가해.
다음 경우에는 사용하지 마세요
의미 없는 스냅샷과 부서지기 쉬운 내부 검사는 피하세요. 예방한다고 주장하기 전에 먼저 원래 실패를 재현해 보세요.
코드에서 사용된 이름
reproduce failure → assert corrected behavior 출시하기 전에
Check the environment and prepared test data (fixture). Define a result you can observe, failure and edge cases, isolation, stable inputs, useful error details, and cleanup. Set a time budget, owner, and flaky-test rule.
Outcome：Complete the task with 회귀 테스트 (Regression Test)。 User context：예전에는 다시 시도할 때 중복 결제가 발생했어요. 새 테스트는 결제 키를 반복 사용하고 딱 한 번만 결제되는지 확인해요. Validation approach：회귀 테스트 (Regression Test)。 Why it fits：반복되는 버그, 확실한 계약, 핵심 흐름, 또는 다시 실패할 수 있는 예외 케이스를 위해 하나 추가해. Do not use it when：의미 없는 스냅샷과 부서지기 쉬운 내부 검사는 피하세요. 예방한다고 주장하기 전에 먼저 원래 실패를 재현해 보세요. Test requirements: Name the system and test environment. Define prepared test data, other inputs, and the result you can observe. Include failure and edge cases, allowed error, isolation, and cleanup. Test operations: Make failures easy to diagnose. Control random or changing inputs. Name an owner. Keep the test fast and simple enough for its release gate. Acceptance criteria: The test fails for the known bug and passes after the fix. It repeats in the target environment, gives useful evidence, and does not expose or change unrelated data. Evidence and limits (evidence boundary)：하나의 공식 표준이 전체 용어를 통제하지 않음. 의미는 팀, 플랫폼 또는 프레임워크마다 달라질 수 있음. Unknowns to confirm: Release gate, environment, prepared test data, allowed error, time budget, owner, and flaky-test rule.
이 요청을 확인하세요
Review how 회귀 테스트 (Regression Test) is used now. Definition: 회귀 테스트는 나중에 코드가 바뀌어서 예전에 잘 되던 기능이 망가지지 않았는지 확인해요. Release checks: Check the environment and prepared test data (fixture). Define a result you can observe, failure and edge cases, isolation, stable inputs, useful error details, and cleanup. Set a time budget, owner, and flaky-test rule. Before changing code, list the evidence, gaps, severity, and the smallest safe fix.