QA Agent 병렬 실행
나는 어제 파이프라인 8단계로 재구성한 뒤라 오늘은 실행 성능을 잡는 날이었다.
QA Agent가 테스트케이스를 순차 실행하다
보니 케이스가 늘어나면 실행 시간이 선형적으로 길어지는 게 문제였다.
그리고 테스트 환경 mock도 산통되어 있어서 이것도 같이 정리했다.
순차에서 lane 병렬로
그 전까지는 테스트케이스를 하나씩 순차 실행했다.
케이스가 10개면 10번 직렬로 도는 거다.
당연히 느리다.
그래서 lane 기반 병렬 실행을 도입했다.
테스트케이스들을 의존성 그래프로 분석해서 서로 독립적인 것끼리 묶은 다음, 여러 lane으로 동시에 돌리는 방식이다.
Planner가 케이스 수와 의존성을 보고 1~5개 범위에서 lane 수를 동적으로 선택한다.
여기서 핵심은 같은 lane 안에 있는 케이스들은 세션과 페이지 상태를 공유한다는 점이다.
그러니까 같은 브라우저 세션으로 로그인해둔 상태를 다음 케이스가 이어받아 쓸 수 있다.
이게 되면 로그인 같은 공통 선행 작업을 매번 반복하지 않아도 된다.
의존성 처리
병렬로 돌리려면 어떤 케이스가 먼저 끝나야 다음 케이스를 실행할 수 있는지, 그 의존 관계를 정확히 알아야 한다.
처음에는 여러 의존성 유형이 있었는데 너무 복잡해서 하드 의존성만 남겼다.
선행 케이스가 반드시 성공해야만 다음 케이스를 실행할 수 있는 관계만 남기고, “순서상 도움은 되지만 필수는 아닌” 소프트 의존성은 제거했다.
그리고 하위 단계 차단 설정이라는 플래그를 만들었다.
어떤 케이스가 실패하면 그 케이스에 의존하는 하위 케이스들을 자동으로 blocked 처리하는 건데, 실패한 케이스 때문에 의존 케이스들이 무의미하게 실행되는 걸 막기 위해서다.
무로그 멈춤
병렬 실행을 돌리다
보니 간헐적으로 로그 없이 멈추는 현상이 있었다.
디버깅하기 까다로운 게, 에러 로그도 없이 그냥 멈춰버리니까 어디서 끊겼는지 알 수가 없다.
결국 같은 세션에서 재시도하도록 보강해서 해결했다.
새 세션을 만드는 게 아니라 기존 세션을 재사용하면서 상태를 유지한 채 재개하는 방식이다.
MSW 마이그레이션
산통된 mock 환경
테스트 환경에서 API 응답을 mock하는 게 산통되어 있었다.
각 테스트마다 따로 mock을 두니까 중복도 많고 API 스펙이 바뀌면 mock을 일일이 찾아서 고쳐야 했다.
이걸 Shared API 기반 MSW(Mock Service Worker) worker로 통일했다.
API 스펙을 한 곳에서 관리하고 모든 테스트가 같은 worker를 바라보게 만들었다.
스펙이 바뀌면 한 곳만 고치면 된다.
MSW가 익숙하지 않다면, 브라우저 Service Worker 레벨에서 네트워크 요청을 가로채서 mock 응답을 주는 도구다. 실제 네트워크를 안 거쳐도 되니까
테스트가 빠르고 안정적이다.
마무리
병렬 실행으로 전환하고 나니까 케이스가 많아도 실행 시간이 크게 단축됐다.
특히 의존성 없는 케이스들이 동시에 돌아가니까 체감이 확 된다.
MSW 통일도 유지보수 측면에서 이득이다.
더 이상 mock 스펙이 여기저기 흩어지지 않으니까 API 변경 시 수정 지점이 한 곳으로 모인다.