재현 가능한 failure triage evidence loop

1. 01

   찾아보기 · 기초

   관찰 가능한 계약에서 oracle과 negative control을 짝지어, 통과 수가 아니라 잘못된 구현을 실제로 거부하는지 판정한다.

   상황

   정상 구현과 서로 다른 결함을 가진 mutant가 있을 때, 후보 test가 계약을 식별하는 oracle인지 단순 실행 확인인지 구분합니다.

   문제

   입력 partition·관찰값·assertion을 표로 만들고 각 test가 정상 구현을 수용하면서 최소 한 negative control을 거부하는지 판정하세요.

   제공 자료

   • Input fixture: 할인 금액 계산기, 경계값 네 개, 정상 구현 한 개와 off-by-one·부호 반전 mutant
   • oracle은 실행 결과를 계약상의 expected value 또는 invariant와 비교하는 판정 규칙입니다.
   • negative control은 의도적으로 잘못된 구현이나 입력을 사용해 test가 실패할 능력을 확인합니다.
   • `raises`만 확인할 때는 예외 class뿐 아니라 어느 입력 경계에서 왜 발생해야 하는지도 계약에 포함합니다.
   • 판정 경계: contract·oracle·negative control·fixture scope·teardown·case id·outcome·first failing phase·reproduction key·redacted context만 채점합니다. test 개수와 통과율만으로 정확성을 판정하지 않습니다.
   • Privacy: 실제 사용자 repository·credential·환경변수·운영 log를 읽지 않고 synthetic implementation과 고정 fixture만 사용합니다.
   • 공개/비공개 경계: 공개 DTO에는 self-review 기준만 둡니다. exact-runtime program·hidden expected output·private mutant sentinel·server grader는 production import graph 밖에 둡니다.
   • 검증 조건: Python 의미는 exact Python 3.14.6에서 fail-closed로 확인합니다. pytest fixture·parametrize·xfail·caplog 고유 의미는 별도 Python 3.14.6 + pytest==9.0.0 실행 증거가 있어야 검증되며 이 공개 명세는 그 실행을 주장하지 않습니다.
   • 과장 금지: coverage 100%, 많은 assertion, AI 생성 test, 한 번의 green run은 oracle 품질·무결함·모든 자격·대회 문제의 정답을 보증하지 않습니다.

   비교표 · 관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.

   정답 대신 4단계 힌트 보기

   1. 관찰

      재현 가능한 failure triage evidence loop에서 expected, actual, exception/warning/log, state before/after를 섞지 말고 따로 기록하세요.

   2. 개념

      triage는 expected·environment·collection manifest·state baseline을 고정한 뒤 한 failure axis만 주입한다.

   3. 다음 도움

      내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.

   내 답과 맞춰 볼 기준 보기정답과 비교
2. 02

   먼저 생각하기 · 기초

   fixture setup·yield·teardown·scope를 따라가며 공유 상태와 순서 의존이 다음 test에 전파되는 결과를 예측한다.

   상황

   네 failure-localization 장면에서 fresh fixture, 약한 신호, 누수되거나 잘못 patch된 경계가 다음 phase에 남기는 결과를 예측합니다.

   문제

   4×3×4 matrix의 각 상태에 setup owner·주입한 결함·최초 판별 지점·replay 결과를 기록하고, 격리되지 않은 상태를 표시하세요.

   제공 자료

   • Input fixture: oracle, fixture, patch·logging, deterministic triage 장면과 세 공통 case
   • function-scoped fixture는 각 test 호출마다 새 상태를 만들고 yield 뒤 teardown을 수행해야 한다는 계약으로 분석합니다.
   • teardown 실패와 shared mutable은 현재 test의 assertion이 green이어도 뒤 test의 baseline을 바꿀 수 있습니다.
   • patch는 정의된 원본이 아니라 system under test가 이름을 lookup하는 namespace에 적용해야 합니다.
   • 판정 경계: contract·oracle·negative control·fixture scope·teardown·case id·outcome·first failing phase·reproduction key·redacted context만 채점합니다. test 개수와 통과율만으로 정확성을 판정하지 않습니다.
   • Privacy: 실제 사용자 repository·credential·환경변수·운영 log를 읽지 않고 synthetic implementation과 고정 fixture만 사용합니다.
   • 공개/비공개 경계: 공개 DTO에는 self-review 기준만 둡니다. exact-runtime program·hidden expected output·private mutant sentinel·server grader는 production import graph 밖에 둡니다.
   • 검증 조건: Python 의미는 exact Python 3.14.6에서 fail-closed로 확인합니다. pytest fixture·parametrize·xfail·caplog 고유 의미는 별도 Python 3.14.6 + pytest==9.0.0 실행 증거가 있어야 검증되며 이 공개 명세는 그 실행을 주장하지 않습니다.
   • 과장 금지: coverage 100%, 많은 assertion, AI 생성 test, 한 번의 green run은 oracle 품질·무결함·모든 자격·대회 문제의 정답을 보증하지 않습니다.

   비교표 · 관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.

   정답 대신 4단계 힌트 보기

   1. 관찰

      재현 가능한 failure triage evidence loop에서 expected, actual, exception/warning/log, state before/after를 섞지 말고 따로 기록하세요.

   2. 개념

      triage는 expected·environment·collection manifest·state baseline을 고정한 뒤 한 failure axis만 주입한다.

   3. 다음 도움

      내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.

   내 답과 맞춰 볼 기준 보기정답과 비교
3. 03

   순서 따라가기 · 익힌 것을 써보기

   parametrize case와 skip·xfail·XPASS 결과를 REPRODUCE_AND_BOUND→OBSERVE_AND_LOCALIZE→TEST_HYPOTHESIS→FIX_AND_VERIFY 네 phase로 추적한다.

   상황

   parametrize table의 각 case가 수집·실행·판정될 때 skip, expected failure, strict XPASS가 어떤 의미를 갖는지 추적합니다.

   문제

   case id별로 입력·expected·mark reason·실제 outcome·release verdict를 작성하고 xfail이 결함을 영구 은폐하지 않도록 만료 조건을 제시하세요.

   제공 자료

   • Input fixture: 정상 3건, 경계 2건, known defect 1건, 잘못 xfail된 정상화 case 1건
   • parametrize는 여러 입력을 같은 test body에 공급하지만 독립 oracle과 읽을 수 있는 case id가 없으면 실패를 국소화하지 못합니다.
   • skip은 test를 실행하지 않는 조건이고 xfail은 실행 결과를 알려진 실패 계약과 비교하는 표시이므로 서로 바꿔 쓰지 않습니다.
   • pytest의 strict XPASS·mark selection·fixture interaction은 Python 3.14.6 + pytest==9.0.0에서 별도 실행해야 합니다.
   • 판정 경계: contract·oracle·negative control·fixture scope·teardown·case id·outcome·first failing phase·reproduction key·redacted context만 채점합니다. test 개수와 통과율만으로 정확성을 판정하지 않습니다.
   • Privacy: 실제 사용자 repository·credential·환경변수·운영 log를 읽지 않고 synthetic implementation과 고정 fixture만 사용합니다.
   • 공개/비공개 경계: 공개 DTO에는 self-review 기준만 둡니다. exact-runtime program·hidden expected output·private mutant sentinel·server grader는 production import graph 밖에 둡니다.
   • 검증 조건: Python 의미는 exact Python 3.14.6에서 fail-closed로 확인합니다. pytest fixture·parametrize·xfail·caplog 고유 의미는 별도 Python 3.14.6 + pytest==9.0.0 실행 증거가 있어야 검증되며 이 공개 명세는 그 실행을 주장하지 않습니다.
   • 과장 금지: coverage 100%, 많은 assertion, AI 생성 test, 한 번의 green run은 oracle 품질·무결함·모든 자격·대회 문제의 정답을 보증하지 않습니다.

   비교표 · 관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.

   정답 대신 4단계 힌트 보기

   1. 관찰

      재현 가능한 failure triage evidence loop에서 expected, actual, exception/warning/log, state before/after를 섞지 말고 따로 기록하세요.

   2. 개념

      triage는 expected·environment·collection manifest·state baseline을 고정한 뒤 한 failure axis만 주입한다.

   3. 다음 도움

      내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.

   내 답과 맞춰 볼 기준 보기정답과 비교
4. 04

   내 말로 설명하기 · 익힌 것을 써보기

   mock·stub·fake의 역할, patch-where-looked-up과 autospec이 협력 객체 경계를 어떻게 검증하는지 설명한다.

   상황

   service module이 collaborator를 import한 뒤 호출하는 코드에서 어느 namespace를 patch해야 하고 autospec이 어떤 interface drift를 잡는지 설명합니다.

   문제

   definition site부터 lookup site까지 binding graph를 그리고 real·fake·stub·mock·spy 중 필요한 test double을 선택한 뒤 호출 계약을 검증하세요.

   제공 자료

   • Input fixture: gateway.send를 service namespace로 import한 함수, 잘못된 source patch, lookup-site patch, signature가 어긋난 mock
   • patch target은 함수가 최초 정의된 곳이 아니라 system under test가 실행 중 그 이름을 lookup하는 곳입니다.
   • autospec은 대상 signature를 반영해 잘못된 호출을 조기에 거부하지만 business semantics나 반환값의 진실성을 자동 보장하지 않습니다.
   • mock 호출 횟수만 확인하면 실제 입력 payload·순서·결과 처리 계약을 놓칠 수 있습니다.
   • 판정 경계: contract·oracle·negative control·fixture scope·teardown·case id·outcome·first failing phase·reproduction key·redacted context만 채점합니다. test 개수와 통과율만으로 정확성을 판정하지 않습니다.
   • Privacy: 실제 사용자 repository·credential·환경변수·운영 log를 읽지 않고 synthetic implementation과 고정 fixture만 사용합니다.
   • 공개/비공개 경계: 공개 DTO에는 self-review 기준만 둡니다. exact-runtime program·hidden expected output·private mutant sentinel·server grader는 production import graph 밖에 둡니다.
   • 검증 조건: Python 의미는 exact Python 3.14.6에서 fail-closed로 확인합니다. pytest fixture·parametrize·xfail·caplog 고유 의미는 별도 Python 3.14.6 + pytest==9.0.0 실행 증거가 있어야 검증되며 이 공개 명세는 그 실행을 주장하지 않습니다.
   • 과장 금지: coverage 100%, 많은 assertion, AI 생성 test, 한 번의 green run은 oracle 품질·무결함·모든 자격·대회 문제의 정답을 보증하지 않습니다.

   서로 이어지는 모습을 그리기 · 관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.

   정답 대신 4단계 힌트 보기

   1. 관찰

      재현 가능한 failure triage evidence loop에서 expected, actual, exception/warning/log, state before/after를 섞지 말고 따로 기록하세요.

   2. 개념

      triage는 expected·environment·collection manifest·state baseline을 고정한 뒤 한 failure axis만 주입한다.

   3. 다음 도움

      내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.

   내 답과 맞춰 볼 기준 보기설명 기준과 비교
5. 05

   빈칸 채우기 · 도전

   statement·branch coverage와 oracle strength를 분리하고, 실행된 분기에서도 살아남는 mutant를 잡는 assertion을 완성한다.

   상황

   모든 statement와 branch가 실행되지만 잘못된 결과를 반환하는 mutant가 살아남는 suite의 빈 assertion을 완성합니다.

   문제

   coverage report가 알려 주는 실행 증거와 알려 주지 않는 oracle 품질을 분리하고, 각 branch의 결과 관계를 검증하는 최소 assertion을 작성하세요.

   제공 자료

   • Input fixture: 세 분기가 모두 실행된 parser, 반환값을 뒤바꾸는 mutant, statement·branch coverage 요약
   • statement coverage는 어떤 line이 실행되었는지, branch coverage는 가능한 source-destination 전이가 관찰되었는지 측정합니다.
   • coverage는 assertion이 올바른 expected를 사용했는지 또는 mutant를 거부했는지 증명하지 않습니다.
   • measurement context를 쓰면 어느 test가 line을 실행했는지 분리할 수 있지만 그 test의 oracle strength는 별도 검증해야 합니다.
   • 판정 경계: contract·oracle·negative control·fixture scope·teardown·case id·outcome·first failing phase·reproduction key·redacted context만 채점합니다. test 개수와 통과율만으로 정확성을 판정하지 않습니다.
   • Privacy: 실제 사용자 repository·credential·환경변수·운영 log를 읽지 않고 synthetic implementation과 고정 fixture만 사용합니다.
   • 공개/비공개 경계: 공개 DTO에는 self-review 기준만 둡니다. exact-runtime program·hidden expected output·private mutant sentinel·server grader는 production import graph 밖에 둡니다.
   • 검증 조건: Python 의미는 exact Python 3.14.6에서 fail-closed로 확인합니다. pytest fixture·parametrize·xfail·caplog 고유 의미는 별도 Python 3.14.6 + pytest==9.0.0 실행 증거가 있어야 검증되며 이 공개 명세는 그 실행을 주장하지 않습니다.
   • 과장 금지: coverage 100%, 많은 assertion, AI 생성 test, 한 번의 green run은 oracle 품질·무결함·모든 자격·대회 문제의 정답을 보증하지 않습니다.

   컴퓨터 안내와 나온 결과 · 관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.

   정답 대신 4단계 힌트 보기

   1. 관찰

      재현 가능한 failure triage evidence loop에서 expected, actual, exception/warning/log, state before/after를 섞지 말고 따로 기록하세요.

   2. 개념

      triage는 expected·environment·collection manifest·state baseline을 고정한 뒤 한 failure axis만 주입한다.

   3. 다음 도움

      내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.

   내 답과 맞춰 볼 기준 보기답과 설명 함께 비교
6. 06

   틀린 곳 고치기 · 도전

   시간·난수·전역 상태·수행 순서·외부 I/O가 만든 flaky test를 재현 seed와 최소 실패 순서로 국소화한다.

   상황

   단독·전체·역순·고정 seed 실행 결과가 달라지는 test suite에서 비결정 입력과 state leak을 분리해 최초 원인을 디버그합니다.

   문제

   실패 signature를 고정하고 실행 순서·seed·clock·locale·shared state를 한 축씩 통제해 최소 재현 case와 안정화 수정안을 제시하세요.

   제공 자료

   • Input fixture: 현재 시각, 난수, module-level cache, 순서가 섞인 세 test와 간헐 실패 report
   • retry로 green을 얻는 것은 재현 증거가 아니며 최초 실패와 seed·순서를 보존해야 합니다.
   • clock·random generator·filesystem·network는 dependency로 주입하거나 명시적 fixture owner 아래 격리합니다.
   • flaky test를 무조건 삭제하거나 broad xfail하면 product race·state leak·timing defect를 숨길 수 있습니다.
   • 판정 경계: contract·oracle·negative control·fixture scope·teardown·case id·outcome·first failing phase·reproduction key·redacted context만 채점합니다. test 개수와 통과율만으로 정확성을 판정하지 않습니다.
   • Privacy: 실제 사용자 repository·credential·환경변수·운영 log를 읽지 않고 synthetic implementation과 고정 fixture만 사용합니다.
   • 공개/비공개 경계: 공개 DTO에는 self-review 기준만 둡니다. exact-runtime program·hidden expected output·private mutant sentinel·server grader는 production import graph 밖에 둡니다.
   • 검증 조건: Python 의미는 exact Python 3.14.6에서 fail-closed로 확인합니다. pytest fixture·parametrize·xfail·caplog 고유 의미는 별도 Python 3.14.6 + pytest==9.0.0 실행 증거가 있어야 검증되며 이 공개 명세는 그 실행을 주장하지 않습니다.
   • 과장 금지: coverage 100%, 많은 assertion, AI 생성 test, 한 번의 green run은 oracle 품질·무결함·모든 자격·대회 문제의 정답을 보증하지 않습니다.

   순서대로 적기 · 관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.

   정답 대신 4단계 힌트 보기

   1. 관찰

      재현 가능한 failure triage evidence loop에서 expected, actual, exception/warning/log, state before/after를 섞지 말고 따로 기록하세요.

   2. 개념

      triage는 expected·environment·collection manifest·state baseline을 고정한 뒤 한 failure axis만 주입한다.

   3. 다음 도움

      내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.

   내 답과 맞춰 볼 기준 보기답과 설명 함께 비교
7. 07

   직접 만들기 · 도전

   traceback의 deepest application frame에서 가설을 세우고 breakpoint·pdb 관찰·반증 실험·회귀 test를 잇는 triage loop를 구현한다.

   상황

   중첩 호출에서 발생한 예외의 traceback과 debugger snapshot을 이용해 증상이 아닌 최초 원인 가설을 세우고 반증 실험을 구현합니다.

   문제

   재현 입력을 고정하고 deepest application frame·관련 local·call path를 관찰한 뒤 하나의 가설, 반증 예측, 최소 수정, 회귀 test를 작성하세요.

   제공 자료

   • Input fixture: 정규화 함수 안의 ZeroDivisionError, traceback frame chain, post-mortem debugger 관찰 지점
   • traceback은 호출 경로와 frame을 제공하지만 원인 설명 자체는 아니므로 관찰에서 가설로 넘어가는 추론을 기록합니다.
   • `breakpoint()`와 pdb post-mortem은 관련 frame의 local·control flow를 관찰하는 도구이며 임의 값을 바꿔 green을 만드는 것이 수정 증거는 아닙니다.
   • 전체 traceback 전문·절대 path·비밀 local을 공개 evidence로 저장하지 않고 frame name·line label·redacted value class만 남깁니다.
   • 판정 경계: contract·oracle·negative control·fixture scope·teardown·case id·outcome·first failing phase·reproduction key·redacted context만 채점합니다. test 개수와 통과율만으로 정확성을 판정하지 않습니다.
   • Privacy: 실제 사용자 repository·credential·환경변수·운영 log를 읽지 않고 synthetic implementation과 고정 fixture만 사용합니다.
   • 공개/비공개 경계: 공개 DTO에는 self-review 기준만 둡니다. exact-runtime program·hidden expected output·private mutant sentinel·server grader는 production import graph 밖에 둡니다.
   • 검증 조건: Python 의미는 exact Python 3.14.6에서 fail-closed로 확인합니다. pytest fixture·parametrize·xfail·caplog 고유 의미는 별도 Python 3.14.6 + pytest==9.0.0 실행 증거가 있어야 검증되며 이 공개 명세는 그 실행을 주장하지 않습니다.
   • 과장 금지: coverage 100%, 많은 assertion, AI 생성 test, 한 번의 green run은 oracle 품질·무결함·모든 자격·대회 문제의 정답을 보증하지 않습니다.

   순서대로 적기 · 관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.

   정답 대신 4단계 힌트 보기

   1. 관찰

      재현 가능한 failure triage evidence loop에서 expected, actual, exception/warning/log, state before/after를 섞지 말고 따로 기록하세요.

   2. 개념

      triage는 expected·environment·collection manifest·state baseline을 고정한 뒤 한 failure axis만 주입한다.

   3. 다음 도움

      내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.

   내 답과 맞춰 볼 기준 보기답과 설명 함께 비교
8. 08

   새 문제에 써보기 · 새 문제

   구조화 logging context와 비밀값 redaction을 포함한 48-state evidence를 재실행해 AI 생성 test suite의 과장된 신뢰 주장을 거부한다.

   상황

   AI가 작성한 test suite와 logging instrumentation을 48-state matrix로 감사해, 재현 가능하고 비밀을 노출하지 않는 release evidence인지 결정합니다.

   문제

   세 후보 suite에 동일 matrix를 적용하고 최초 실패 phase·mutant kill·replay key·log context·redaction 결과를 근거로 승인 또는 거부하세요.

   제공 자료

   • Input fixture: narrow evidence suite, green-only suite, shared-state·wrong-patch·raw-secret logging suite
   • 구조화 log는 event name·case id·phase·reproduction id 같은 안정 field를 가져야 하며 원문 사용자 데이터와 credential은 allowlist 밖에 둡니다.
   • logger·handler level, filter, formatter, propagation을 분리해 중복·누락과 redaction 적용 위치를 확인합니다.
   • pytest `caplog`의 record·phase 캡처 의미는 Python 3.14.6 + pytest==9.0.0 별도 실행 조건이며 표준 logging 실행만으로 검증됐다고 주장하지 않습니다.
   • 판정 경계: contract·oracle·negative control·fixture scope·teardown·case id·outcome·first failing phase·reproduction key·redacted context만 채점합니다. test 개수와 통과율만으로 정확성을 판정하지 않습니다.
   • Privacy: 실제 사용자 repository·credential·환경변수·운영 log를 읽지 않고 synthetic implementation과 고정 fixture만 사용합니다.
   • 공개/비공개 경계: 공개 DTO에는 self-review 기준만 둡니다. exact-runtime program·hidden expected output·private mutant sentinel·server grader는 production import graph 밖에 둡니다.
   • 검증 조건: Python 의미는 exact Python 3.14.6에서 fail-closed로 확인합니다. pytest fixture·parametrize·xfail·caplog 고유 의미는 별도 Python 3.14.6 + pytest==9.0.0 실행 증거가 있어야 검증되며 이 공개 명세는 그 실행을 주장하지 않습니다.
   • 과장 금지: coverage 100%, 많은 assertion, AI 생성 test, 한 번의 green run은 oracle 품질·무결함·모든 자격·대회 문제의 정답을 보증하지 않습니다.

   비교표 · 관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.

   정답 대신 4단계 힌트 보기

   1. 관찰

      재현 가능한 failure triage evidence loop에서 expected, actual, exception/warning/log, state before/after를 섞지 말고 따로 기록하세요.

   2. 개념

      triage는 expected·environment·collection manifest·state baseline을 고정한 뒤 한 failure axis만 주입한다.

   3. 다음 도움

      내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.

   내 답과 맞춰 볼 기준 보기설명 기준과 비교

8개 답이 남았습니다.