먼저 생각하기 · 기초
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 품질·무결함·모든 자격·대회 문제의 정답을 보증하지 않습니다.
연습과 같은 문제를 다시 풀어 보는 시간이에요. 힌트 없이 먼저 생각해 보세요. 지금 적은 답은 바로 합격으로 기록되지 않아요.
