학습 본문으로 건너뛰기
VAIRODE
pytest·debugging·logging46번째 작은 수업
오늘은 질문 하나만 해결해요46 / 52

도움 없이 한 번 더 풀어보기

재현 가능한 failure triage evidence loop

오늘의 질문

oracle·fixture scope·mock boundary·logging context가 섞인 failure를 baseline→inject→localize→replay 순서로 국소화하고 sealed regression evidence를 만든다. 이 판단을 생략하면 통과한 test와 많은 log가 있어도 결함을 놓치거나 잘못된 수정을 승인할 수 있습니다.

아직 답을 몰라도 괜찮아요. 아래 작은 예시를 보고 먼저 예상해 보세요.

01 · 혼자 확인해요

연습한 문제를 다시 풀며 혼자 확인하기

지금은 방금 연습한 문제를 다시 보는 시간이에요.아직 “완전히 익혔다”고 기록하지 않아요. 나중에 모양이 다른 문제도 도움 없이 풀면 그때 다시 확인할 수 있어요.

답과 과정 확인
80% 이상
내 말로 설명
80% 이상
막힌 곳 고치기
80% 이상
다른 문제에 써보기
80% 이상
스스로 확인하며 작성 중인 답0 / 4
  1. 01

    먼저 생각하기 · 기초

    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 품질·무결함·모든 자격·대회 문제의 정답을 보증하지 않습니다.

    연습과 같은 문제를 다시 풀어 보는 시간이에요. 힌트 없이 먼저 생각해 보세요. 지금 적은 답은 바로 합격으로 기록되지 않아요.

    정답과 비교
  2. 02

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

    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 품질·무결함·모든 자격·대회 문제의 정답을 보증하지 않습니다.

    연습과 같은 문제를 다시 풀어 보는 시간이에요. 힌트 없이 먼저 생각해 보세요. 지금 적은 답은 바로 합격으로 기록되지 않아요.

    설명 기준과 비교
  3. 03

    틀린 곳 고치기 · 도전

    시간·난수·전역 상태·수행 순서·외부 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 품질·무결함·모든 자격·대회 문제의 정답을 보증하지 않습니다.

    연습과 같은 문제를 다시 풀어 보는 시간이에요. 힌트 없이 먼저 생각해 보세요. 지금 적은 답은 바로 합격으로 기록되지 않아요.

    답과 설명 함께 비교
  4. 04

    새 문제에 써보기 · 새 문제

    구조화 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 품질·무결함·모든 자격·대회 문제의 정답을 보증하지 않습니다.

    연습과 같은 문제를 다시 풀어 보는 시간이에요. 힌트 없이 먼저 생각해 보세요. 지금 적은 답은 바로 합격으로 기록되지 않아요.

    설명 기준과 비교

4개 답이 남았습니다.

02 · 나중에 한 번 더

모양이 다른 문제에서도 같은 생각을 써봐요

td46 재현 가능한 failure triage evidence loop: oracle·fixture scope·mock boundary·logging context가 섞인 failure를 baseline→inject→localize→replay 순서로 국소화하고 sealed regression evidence를 만든다.의 미공개 fixture에서 AI 없이 expected·first divergence·oracle·failure owner를 결정하고 재현 명령과 non-disclosure receipt를 제출한다.

검증 과제

AI가 제안한 재현 가능한 failure triage evidence loop의 test·diagnostic 후보를 생성하되 학습자가 먼저 쓴 expected result와 독립 oracle을 바꾸지 않고 반례로 검증한다. 해법에 weak oracle, shared fixture state, wrong patch lookup, wrong log level, secret leak, branch gap 또는 order dependency 중 하나 이상을 심어 독립 evidence로 찾아 수정한다.