테스트의 우연한 통과에서 CASE별 품질 승인으로 — v0.17.9 (2026-09-10)
최신 사용자 결정: 와드업·관리자 CASE·단위·컴포넌트·DB 검사를 모두 자동 대상에서 제외했다. 현재75건·1,125조건을 적용하며 이전79건/78건 판정은 이력이다. 관리자 타입·빌드는 유지한다.
- 기간: 2026-09-09~10, 조사와 구현. 오너: “17.7 배포 되었으니까 작업 진행해줄래”, 이후 “v0.17.9에 적용”.
- 랜딩: 앱 PR1497, release merge
19e97f215c9c77d46a6eb6be511158579ddf3a2c. migration·Edge 변경 없음, Production 미반영. 문서·관리자는 PR8에서 독립 검증한다. - 설계서: #1478 구현 계획.
- 정본: 품질 기준 15개, 79건 현행 감사.
- 도구: 앱 fixture와 checkpoint·control·cleanup·diagnostic reporter, 필수 증거 집계기. 외부 work의 감사 생성기는 원본 SHA·인용값·명시 판정을 검증한다. 앱 CI는 문서를 읽지 않는다.
- 게이트: 앱 check 3,505 pass / 0 fail / 33 조건부 DB skip, 공통 Chromium 23/23. 05:05 KST precheck에서 실제 pgTAP 130파일·2,328단언, SQL 취소 2개, 동시 CRUD·통계 수렴 통과. 앱 필수 56건과 viewport 22건이 최초 시도에 통과했다. 부분 실행을 full CI로 보고하지 않는다.
- 버그리포트: BUG-091.
- 계약: 품질 기준의 적용 상태와 관리자 독립 필수 E2E.
Phase 현황
| Phase | 내용 | 상태 |
|---|---|---|
| Phase 1 | 필수 단언·시간·정리와 기존 누락 보완 | 완료, 앱 ded0567·관리자 8ee8c4b |
| Phase 2 | 목적별 결함·요청 수명·첫 실패 증거·79×15 판정 | 구현·로컬·감사 완료, 앱 93d4cad·관리자 37aa8f0 |
1. 배경
CASE-045가 연속 실패한 뒤 hosted CI 재실행에서 통과한 일을 계기로, 오너는 테스트 자체의 타이밍 문제를 허용하지 않는 품질관리를 요청했다. 기존 18개 항목을 중복 없이 15개 필수 조건으로 통합했다. 관리자 저장소 분리 후에도 앱 56 + 화면 22 + 관리자 1 = 79 CASE를 유지했다.
2. 문제 제기
실행 한 번의 통과는 필수 단언, 시험 상황 발생, 결함 탐지, 정리의 완결성을 입증하지 않았다. 최초 감사는 공통 시간·재시도 설정과 개별 누락을 확인했다. 후속 실행에서도 준비 조회와 문서 교체, 페이지의 자동 저장과 Auth 삭제가 경합했다.
3. 해결 방안
원칙
- D1: 15개 조건 중 하나라도 위반하거나 증거가 없으면 CASE 승인을 거절한다.
- D2: 실제 v0.17.7 Production에서 작업을 시작한다. 작업 중 v0.17.8 배포 후 오너가 v0.17.9 이동을 승인했다.
- D3: 앱·백엔드와 문서·관리자를 분리하고 관리자 CI에 앱 checkout 의존을 만들지 않는다.
접근
시간 증가와 CASE 재시도는 실제 선행 조건을 보장하지 않아 기각했다. 실제 사건·단언·복원·정리를 관측하고, 같은 reader가 대표 오답을 검출하도록 했다. 서버 자체가 검증 목적인 경우에는 별도 SQL 결함 7개를 주입해 원래 단언의 최초 실패를 확인했다. 수동 수리 검증은 원본과 다른 실행으로 기록했다.
4. 적용한 내용
Phase 1 — 단언과 정리
Playwright의 실제 step·expect 사건으로 필수 checkpoint를 확인한다. 빈 callback, 빠진 await, 삼킨 실패와 누락을 거절한다. 화면 22건의 checkpoint 117개와 정확한 하단 표면 목록을 연결했다. 정답·경계 단언을 보완하고 준비 중 실패에서도 정리를 실행한다.
Phase 2 — 실제 탐지와 판정
각 CASE의 정상 → DOM·CSS·HTTP 경계 오답 → 같은 reader의 불일치 → 복원을 확인했다. SQL 결함은 소유자 분리 038·044, 멱등성 041, 권한 053·056, 원자성 055·056의 7개다. 요청과 문서·탭·리스너의 실제 종료를 보존하며 Auth 계정보다 페이지를 먼저 정리한다. 모바일 화면 import 완료도 performance mark로 관측한다.
관리자는 앱이 발행한 고정 artifact의 설정과 SQL 188개로 독립 DB를 준비한다. 관리자 필수 두 시나리오를 실행하며, artifact 발행 성공과 hosted 소비 성공을 구분한다.
작업 중 드러난 것
CASE-014·019의 최초 실패와 부정확했던 SQL 결함 주입·판정기의 거절도 보존했다. 관계없는 예외는 탐지 성공으로 인정하지 않았다. 관리자 hosted CI의 읽기 전용 secret이 없어 마지막 품질 조건을 U로 남겼다. 보호 규칙 완화, 큐 밖 병합, full 중복 실행, Production DB 변경은 없었다.
5. 적용 결과
| 항목 | 전 → 후 |
|---|---|
| 최초 감사 품질 승인 | 당시 0/79 → 현재 78/79. 서로 다른 SHA와 근거를 명시 |
| 마지막 수리의 실제 실행 | 2f 후보 76/78 → 93d 후보 78/78. 각각 별도 최초 시도 |
| 현재 품질 조건 | 정적 P576/U609 → 실제 실행·의미 검토 P1,184/F0/U1 |
| SQL 대표 결함 | 증거 없음 → 7/7, 21단계의 목표 실패와 복원 정상 |
| 공통 브라우저 회귀 | 정상·취소·문서 교체·중도 실패·정리 23/23 |
| v0.17.9 통합 | PR1497의 Merge Check 성공 → release 19e97f2 |
| Production·관리자 hosted | 이번 Production 미반영. 관리자 기준 14 미검증 |
6. 이번 개선으로 향상된 것
실행 통과와 품질 승인을 분리하고 누락·예외·미완료 작업을 성공으로 넘기던 경로를 막았다. 각 CASE의 목적, 정답, 금지 부작용, 대표 결함, 정리를 소스와 실제 값으로 추적할 수 있다. 검토 관측 7,431개 중 판정에서 인용한 5,781개 값과 원본 해시를 공개 JSON에 남겼다. 미래의 모든 실행 순서에 대해 무결점을 수학적으로 보장한다는 주장은 하지 않는다.
후속 범위 변경
사용자는 CASE-056만 제외한 뒤 와드업·관리자 관련 검사 전체로 범위를 넓혔다. CASE-007/018/055도 수동으로 전환해 필수78→75건이며, 관련 단위·컴포넌트·DB 검사는 자동 발견에서 제외한다. 기존 검증 소스·최초 결과는 보존하며 성공으로 위장하지 않는다.
남은 것
제외된 관리자 CASE-056의 기존 기준 14는 U로 보존하지만 현재 필수 범위의 미완료 항목은 아니다. v0.17.9의 staging·Production 승격과 배포는 현재 작업 PR의 release 통합과 구분하며 아직 완료로 표시하지 않는다.