A red Playwright build can't tell you whose fault it is

개요

Playwright 빌드 실패 시, 애플리케이션의 회귀(regression) 문제인지 테스트 코드 자체의 노후화(stale) 문제인지 구분하기 어려운 기존 방식의 한계를 지적하고, 이를 해결하기 위해 UI 컨트롤을 명시적으로 명명하고 기계가 읽을 수 있는 형태로 기록하는 새로운 접근 방식을 제시합니다.

주요 내용

* Playwright 실패 보고의 모호성: Playwright 테스트 실패 시 보고되는 내용은 특정 셀렉터의 타임아웃 등 기술적인 정보만을 제공할 뿐, 실제 애플리케이션의 버그인지, 테스트 코드의 UI 변경 사항 미반영으로 인한 문제인지 근본적인 원인을 파악하기 어렵습니다.
* test.step()의 한계: test.step()을 사용하여 테스트 단계를 설명하더라도, 이는 사람이 직접 작성해야 하는 정보이므로 유지보수가 필요하며 코드 변경 시 설명이 불일치하는 문제가 발생하여 결국 사람이 직접 간극을 메워야 합니다.
* 컨트롤 명명(Naming Controls)의 중요성: 각 UI 컨트롤(Input, Table, Button 등)을 생성할 때 고유한 이름, 셀렉터, 사람이 이해할 수 있는 레이블을 부여하여 관리합니다. 이를 통해 테스트 실행 시 어떤 UI 컨트롤이 조작되었는지 명확히 기록할 수 있습니다.
* 기계 가독형 기록 생성: UI 컨트롤을 명명함으로써 테스트 실행 결과가 "Type '...' into field '...'"와 같은 사람이 읽기 쉬운 보고서뿐만 아니라, { "action": "click", "controlType": "button", "name": "Place order", "selector": "[data-testid=\"place-order\"]", "status": "failed" }와 같은 기계가 분석할 수 있는 형태로 기록됩니다.
* Pull Request(PR)와의 연동을 통한 원인 분석: 테스트에서 조작된 UI 컨트롤의 셀렉터 정보와 PR에서 변경된 UI 요소의 셀렉터 정보를 매칭하여, 테스트 실패가 PR의 변경 사항과 직접적인 관련이 있는지(테스트 노후화) 또는 다른 회귀 문제인지(regression candidate) 판별합니다.
* LLM 활용의 초기 문제점 및 개선: 초기에는 실패 보고서와 Trace를 LLM에 직접 전달하여 원인을 추론하게 했으나, 증상만을 기반으로 잘못된 추론을 생성하는 한계가 있었습니다. 이후, 코드 수준에서 PR의 변경 사항과 테스트가 조작한 컨트롤을 직접 비교하여 범위를 좁힌 후 LLM이 최종 판단을 내리도록 개선했습니다.
* 해결의 핵심: 명확한 기록과 결정론적 연동: 실패 지점의 UI 컨트롤을 명확히 기록하고, 이를 PR의 변경 사항과 결정론적으로 연동하는 메커니즘이 핵심입니다. 예측(probabilistic)보다는 결정론적(deterministic)인 방식으로 접근하여 신뢰도를 높였습니다.
* 현재의 한계점: 컨트롤이 명명되지 않으면 분석이 불가능하며, 테스트가 직접적으로 접근하지 않는 간접적인 변경 사항(예: 공유 컴포넌트, API 응답 변경)은 감지하기 어렵습니다. 또한, PR이 없는 경우(로컬 실행, 야간 빌드)는 결정론적 분석이 불가능합니다.

시사점

UI 컨트롤을 체계적으로 명명하고 기계 가독형 기록을 생성하는 것은 Playwright와 같은 자동화 테스트의 실패 원인 분석의 정확성과 효율성을 획기적으로 높여, 회귀를 빠르게 식별하고 테스트 코드 유지보수 부담을 줄이는 데 기여할 수 있습니다.