모바일 UI 자동화 프레임워크를 개발하고 버그는 CI가 아닌 제품에서 고치기

## 각 변경을 그 동작을 맡은 모듈에 두기 코드가 어디에서 실행되고 그 산출물을 누가 사용하는지 보여 주는 간결한 모듈 지도를 유지한다. 최소한 다음 책임을 분리한다. - 디바이스 측 드라이버와 여기에서 생성되는 바이너리 - 호스트 측 플랫폼 어댑터와 프로토콜 클라이언트 - 명령 해석, 재시도, 수명주기 제어, 오류 분류 - 공유 명령 모델과 데이터 모델 - 명령줄 인터페이스와 에이전트 대상 인터페이스 - Web 드라이버, 전송 형식 정의, 유틸리티, 모듈 간 테스트 동작을 소유한 위치에 변경을 둔다. 디바이스 상호작용과 시스템 대화상자 처리는 플랫폼 드라이버 또는 호스트 어댑터, 재시도와 명령 순서 제어는 오케스트레이션, 공유 요청 형식은 모델 또는 프로토콜 모듈이 담당한다. 멀리 떨어진 모듈에서 수정하기 쉽다는 이유만으로 그곳에서 소유권 문제를 해결해서는 안 된다. 이 지도를 workflow와 전문 에이전트가 사용하는 단일 기준 정보로 유지한다. 모듈 책임이 변경되면 함께 갱신하여 하위 지침이 어긋나지 않게 한다. ## 동작을 증명할 수 있는 가장 저렴한 테스트 계층 고르기 계층화된 테스트 전략을 사용하고, 동작을 입증할 수 있는 가장 낮은 비용의 계층을 기본으로 선택한다. 1. 독립된 클래스, 파싱, 작은 유틸리티, 국소적인 판단 로직에는 단위 테스트를 사용한다. 2. 디바이스 없이 실행할 수 있는 명령 오케스트레이션, 취소, 스크립트 엔진, 네트워크 경계, 여러 모듈의 연동에는 통합 테스트를 사용한다. 3. 실제 드라이버, 디바이스 또는 브라우저 동작, 운영체제 통합, 전체 사용자 흐름에는 E2E 테스트를 사용한다. 4. 제품이 AI 대상 프로토콜을 제공한다면 모델 동작과 도구의 정확성을 에이전트 인터페이스 평가로 확인한다. fake 또는 프로세스 내부 구성 요소가 계약을 정확히 표현할 수 있는데 테스트를 더 비싼 계층으로 올려서는 안 된다. 반대로 위험이 플랫폼 동작에 있다면 디바이스 수준의 증거를 mock으로 대체해서는 안 된다. ## 통과해야 할 테스트 모음과 실패해야 할 테스트 모음 나누기 예상 결과에 따라 E2E 흐름을 분리한다. 긍정 테스트 모음에는 반드시 성공해야 하는 흐름을 두며, 모든 실패는 회귀이다. 부정 테스트 모음에는 의도적으로 유효하지 않은 assertion 또는 명령을 두며, 예상한 방식으로 실패해야 한다. 테스트 도구가 부정 테스트 모음의 성공 판정을 반전할 수 있으므로 산출물을 해석할 때 테스트 모음의 label을 보존해야 한다. 예상된 부정 결과를 제품 회귀로 진단해서는 안 되며, 통과시키기 위해 부정 흐름을 약화하거나 다시 작성해서도 안 된다. 자동 진단 프로세스가 산출물을 사용한다면 계약에서 부정 경로 분석을 명시적으로 지원하지 않는 한, 실제 긍정 테스트 모음의 실패만 처리하게 제한한다. 산출물은 애플리케이션, 플랫폼, 테스트 모음, 실행 식별자를 포함하는 예측 가능한 계층에 저장한다. ## 하나의 fixture 앱을 모든 플랫폼의 E2E 테스트에 재사용하기 지원하는 모든 플랫폼에서 전체 명령 범위를 검증하기 위해 하나의 기본 fixture 애플리케이션을 사용한다. 같은 흐름을 두 가지 목적으로 재사용한다. 현재 플랫폼 버전에서는 회귀 smoke test로 사용하고, 새로 도입하는 운영체제 버전에서는 호환성 검증으로 사용한다. 동작이 특정 프레임워크에만 해당한다면 기본 애플리케이션을 왜곡하지 말고 전용 fixture workspace를 추가한다. 각 workspace에 자체 흐름과 build artifact를 두고, 수동 실행에서는 하나의 애플리케이션 또는 하나의 흐름으로 범위를 좁힐 수 있게 한다. 테스트 드라이버는 플랫폼과 명시적인 환경 입력을 매개변수로 받는다. 비용이 큰 인프라를 프로비저닝하기 전에 실행 입력을 검증하고, 지원되지 않는 시스템 버전, 누락된 workspace, 모호한 흐름 선택자를 일찍 거부한다. ## 디바이스 실패는 CI 설정이 아닌 드라이버에서 고치기 플랫폼 드라이버가 실제 디바이스 동작을 처리하지 못해 E2E 흐름이 실패한다면 사용자가 실제로 실행하는 드라이버, 호스트 어댑터 또는 fixture 애플리케이션을 수정한다. CI workflow에 에뮬레이터 설정, shell 명령, 명령줄 조정 또는 사전 구성을 추가해 부족한 동작을 숨겨서는 안 된다. workflow 변경이 적절한 범위는 matrix, 보존 기간, trigger, 검증된 실행 입력, 범위가 좁고 문서화된 인프라 예외 등 workflow 자체의 형태이다. 제품 동작을 대신해서는 안 된다. 새 운영체제 버전 검증에도 같은 원칙을 적용한다. CI 전용 준비를 거친 뒤에만 흐름이 성공한다면, 그 준비가 사용자에게 명시된 사전 요구 사항이 아닌 한 제품 호환성 결함이 여전히 존재한다. ## 재시도할 오류를 구분하고 임시 파일은 항상 정리하기 명시적인 dispatcher 또는 executor가 있는 구조화된 비동기 실행을 사용한다. 차단 bridge는 애플리케이션 진입점에만 둔다. 외부로 드러나는 실패를 분류하여 오케스트레이션이 재시도 가능한 상태와 종료 오류를 구분할 수 있게 하고, 모든 실패를 일률적으로 재시도하지 않는다. 임시 파일과 디렉터리는 수명주기를 소유하는 resource manager를 통해 관리한다. 리소스를 소유한 작업 근처에서 manager를 만들고, 그 API를 통해 할당하며, `finally` 경로에서 닫는다. 성공, 실패, 취소 중 어느 경우에도 재귀 정리가 실행되어야 한다. 임시 파일 API를 직접 호출하여 resource manager를 우회해서는 안 된다. 관리되지 않는 파일은 장시간 실행되는 worker에 쌓이고 실패 재현을 어렵게 한다. 디바이스가 필요하지 않을 때는 결정적으로 동작하는 fake 드라이버와 실제 오케스트레이션을 사용해 취소, 시간 제한, supervisor 동작, 정리를 테스트한다. ## 에이전트용 도구와 모델 동작을 따로 테스트하기 명령줄 애플리케이션이 에이전트 대상 server도 제공한다면 서로 다른 두 테스트 그룹을 유지한다. - 요청, 응답, 디바이스 설정, 실패 동작을 검증하는 도구 기능 테스트 - 에이전트가 도구를 올바르게 선택하고 사용하는지 측정하는 모델 동작 평가 선언형 평가 사례와 플랫폼별 설정 스크립트를 사용해 적용 범위를 재현 가능하게 한다. 일반적인 구현 변경에는 빠른 도구 테스트를 실행하고, prompt, 도구 설명, schema, routing 또는 에이전트에게 보이는 동작이 변경되면 더 느린 모델 평가를 실행한다. 모델 score를 기반 도구가 작동한다는 증거로 취급해서는 안 되며, 도구 기능 테스트를 에이전트가 해당 도구를 올바르게 사용한다는 증거로 취급해서도 안 된다. 두 계약은 각각 자체 증거가 필요하다. ## 생성된 바이너리는 손으로 고치지 말고 빌드로 다시 만들기 버전 관리에 포함된 드라이버 바이너리, 패키징된 runner, checksum, 그 밖의 파생 파일을 generator 산출물로 취급한다. 절대 수동으로 편집하지 않는다. 소유 주체의 build task 또는 finalizer를 실행하고, 결과 산출물을 생성한 source 변경과 함께 commit한다. 완료 전에 다음을 확인한다. 1. 변경이 해당 동작을 소유한 모듈에 있다. 2. 충분한 가장 낮은 테스트 계층과 직접 영향을 받는 상위 계층을 실행했다. 3. 긍정 및 부정 테스트 모음을 각각의 계약에 따라 해석했다. 4. 성공, 실패, 취소 후 모두 임시 리소스가 닫히는지 검증했다. 5. 공식 build 경로를 통해 파생 산출물을 다시 생성했다. 6. CI 변경이 제품 결함을 숨기는 것이 아니라 인프라 형태를 설명하는지 확인했다. workflow 문서, fixture 배치, 모듈 소유권 설명을 동기화하여 이후 기여자와 자동 에이전트가 같은 경계를 따르게 한다.