사용자 동작을 중심으로 Playwright로 E2E 테스트 작성하기 - Part 1

글 목록

1. 사용자 동작을 중심으로 Playwright로 E2E 테스트 작성하기 - Part 1
2. 사용자 동작을 중심으로 Playwright로 E2E 테스트 작성하기 - Part 2
3. 사용자 동작을 중심으로 Playwright로 E2E 테스트 작성하기 - Part 3

Intro.

Playwright를 이용하여 E2E 테스트를 진행한 과정을 기록한 글입니다.

E2E 테스트

어플리케이션의 안정성, 신뢰도 등을 위해 QA 단계에서 테스트가 진행되어야 합니다. 수동 테스트는 테스터들의 많은 시간과 노력이 들어가며, 휴먼 에러가 발생할 수 있습니다.

기능이 추가/수정하여 버그가 발생되는 경우 코드를 작성하는 개발자는 어느 정도(?) 사이드 이펙트를 예측할 수 있지만, 어플리케이션을 사용하는 테스터는 발생 원인을 예측할 수 없으므로 처음부터 끝까지 반복하여 테스트를 진행해야 합니다.

어플리케이션의 복잡성이 증가할수록 어느 순간부터 테스트없이 개발하게 된다면 시간이 더 소모됩니다. 특히 복잡한 시나리오에서는 E2E 테스트를 통해 취약점을 파악할 수 있으며 개발 프로세스의 향상으로 효율적인 개발을 할 수 있습니다.

프론트엔드에서 E2E 테스트는 사용자 중심으로 어플리케이션의 유저 시나리오를 검증하는 방법입니다. 단위 테스트에 비해 무겁고 느리지만, 반드시 수행되어야 합니다. 또한 단순히 어플리케이션의 결함을 찾고 예방하는데 그치지 않고, 사용자가 필요로 하는 기능을 이해하고 결과를 예측 가능할 수 있게 도움을 줍니다.

예를 들어 사용자가 로그인을 정상적으로 한다는 시나리오에는

• 사용자가 로그인 페이지에서 접속하고
• 인풋 박스에 올바른 아이디/비밀번호를 입력하고
• 로그인 버튼을 클릭할 때 정상적으로 로그인이 되는

동작이 예상되어야 합니다.

ATDD (인수 테스트 주도 개발)

우리 조직은 개발 프로세스를 이해하는 당사자 간의 협업을 강화하고 요구사항을 명확하게 정의하기 위해서 ATDD 테스팅 방식을 선택하게 되었습니다. ATDD는 인수 조건을 시나리오 형태로 작성하여 검증하므로, 기대 결과가 명확하게 나타납니다. 사용자 시나리오를 통해 전 구간 테스트를 작성함으로써 사용자 의도를 명확하게 전달할 수 있습니다. 사용자 시나리오에 대한 깊은 이해를 기반으로 개발한다면 사용자, 엔지니어, 개발자, 기획자, 테스터들이 하나의 목표를 향해 협력하여 결과물을 도출할 수 있습니다. 또한, 사용자의 의도의 기대를 충족시킬 수 있다고 생각합니다.

Playwright

Mircosoft의 오픈 소스 라이브러리인 Playwright는 최근 테스트 자동화에서 큰 주목을 받고있습니다. Playwright를 선택한 10가지 이유는 다음과 같습니다.

1. 무료로 병렬 실행이 가능하며, 다른 테스팅 도구보다 빠른 속도를 자랑합니다.
   • 외부 솔루션이나 서드파티 도구를 사용하지 않아도 되어 비용 절감이 가능합니다.
   • 속도 비교는 여기에서 확인할 수 있습니다.
2. UI 모드와 디버깅 실행 보고서 기능을 지원하여 테스터의 편의성을 높입니다.
3. 테스트 중 브라우저 페이지 내 JavaScript의 실행 컨텍스트 스코프의 제약을 넘나들 수 있습니다.
   • Multi Tab, Multi User, Multi Origin/Domain, Iframe의 테스트를 구현할 수 있습니다.
4. Chromium, Microsoft Edge, Safari 등 다양한 브라우저를 지원합니다.
5. Microsoft에서 Github로 관리하며, 오픈소스로 기여할 수 있는 환경을 제공합니다.
   • VSCode의 Extension을 지원합니다.
6. 기본적인 장치별 이벤트 외에도 hover, drag 이벤트를 공식적으로 활용하여 테스트가 용이합니다.
   • 툴팁, 슬라이더 등 다양한 동작을 테스트할 수 있습니다.
7. Auth 정보를 Json으로 저장하여 로그인된 상태를 테스트 중에 재사용할 수 있습니다.
   • 의존성을 통해 로그인된 상태를 기준으로 테스트할 수 있습니다.
8. API 테스트를 지원하며, 컴포넌트 테스트(실험 단계)도 가능합니다.
9. Locators 라는 강력한 기능을 활용하여 언제든지 요소를 쉽게 찾을 수 있습니다.
   • Auto Waiting, Retry Ability 기능의 핵심입니다.
   • Role, Text, Label, Placeholder, Alt, Title, TestId, CSS, XPath 등을 통해 요소를 탐색할 수 있습니다.
10. JavaScript 코드를 작성하듯이 테스트 코드를 작성할 수 있어, 다른 테스팅 도구보다 비교적 낮은 러닝커브를 가집니다.
    • Async/Await를 활용하여 비동기를 제어할 수 있습니다.
    • 체이닝없이 코드를 작성할 수 있습니다.

개인적으로 생각하는 Playwright의 아쉬운점과 한계점은 다음과 같습니다.

• 공식문서가 너무나 친절하긴 하지만 분량이 매우 방대하고 레거시 레퍼런스가 많아 초보자에게 다소 어려울 수 있습니다.
• 관련 커뮤니티가 한정적이며 최근 자료의 양이 작습니다.
• HTML Canvas(ex. 차트)에 대해 제약이 있어 특정 상황에서는 다루기 어려울 수 있습니다.
• 다른 테스팅 도구에 비해 API 테스팅 기능이 상대적으로 부족합니다.
• IE 11 이전 버전의 브라우저는 지원하지 않습니다.
• 테스트를 위해 실제 장치가 아닌 에뮬레이터를 사용하는 점이 제한적일 수 있습니다.

위의 이유로 Playwright를 선정하였습니다. 그렇다면 유저 시나리오는 어떻게 작성해야할 지 고민해봤습니다.

시나리오 작성

시나리오는 기본적으로 Given, When, Then 방식으로 구문을 작성합니다.

예제를 통해 시나리오에 대해 설명하도록 하겠습니다.

1. 유저는 데이터 조회 메뉴의 Overview에서 다른 트레인을 선택할 수 있다.

- Given (사전 조건)
유저가 데이터 조회 메뉴의 Overview 영역에 정상적으로 진입합니다.

- When (검증 대상)
셀렉트 박스의 N 번째 위치한 트레인을 선택합니다.

- Then (기대 결과)
N번째 트레인이 선택됩니다.

2. 유저는 대시보드 메뉴에서 베어링 정보 카드를 볼 수 있다.

- Given (사전 조건)
유저가 대시보드 메뉴에 정상적으로 진입합니다.

- When (검증 대상)
유저는 베어링 이미지 위에 마우스를 호버합니다.

- Then (기대 결과)
베어링 정보 카드가 툴팁 형태로 나타납니다.

위에 작성한 시나리오는 어플리케이션을 사용자가 생각하는 기본적인 시나리오입니다.

하지만 실제 테스트 코드로 작성된 시나리오는 다음과 같습니다.

1. 유저는 데이터 조회 메뉴의 Overview에서 다른 트레인을 선택할 수 있다.

- Given (사전 조건)
유저가 성공적으로 로그인하였습니다.
유저가 데이터 조회 메뉴에 정상적으로 진입합니다(메뉴 요소가 정상적으로 렌더링됩니다).
유저가 데이터 조회 메뉴의 Overview 영역에 정상적으로 진입합니다(Overview 영역 요소가 정상적으로 렌더링됩니다).

- When (검증 대상)
(셀렉트 박스를 클릭합니다.)
셀렉트 박스의 N 번째 위치한 트레인을 선택합니다.

- Then (기대 결과)
N번째 트레인이 선택됩니다.
선택된 N번째 트레인의 데이터 조회 메뉴 URL로 이동합니다.

2. 유저는 대시보드 메뉴에서 모든 베어링 정보 카드를 볼 수 있다.

- Given (사전 조건)
유저가 성공적으로 로그인하였습니다.
유저가 대시보드 메뉴에 정상적으로 진입합니다.
유저가 대시보드 메뉴의 베어링 이미지가 1개 이상 있는지 확인합니다.

- When (검증 대상)
유저는 반복하면서 모든 베어링 이미지 위에 마우스를 호버합니다.

- Then (기대 결과)
모든 베어링에 연관된 베어링 정보 카드가 툴팁 형태로 나타납니다.

특정 페이지에 진입하고 특정 요소의 렌더링, 사용자 이벤트 실행은 E2E 테스트 코드에서는 필수적인 부분입니다. 실제로 테스트 코드를 작성하면 예상보다 더 많은 Given (사전 조건)과 When (검증 대상)을 고려해야 합니다.

모든 테스트 항목을 E2E 테스트로 완벽하게 커버하는 것은 어렵습니다. 그러나 요구사항에서부터 사용자 시나리오가 유도되고, 개발된 내용을 통해서 E2E 테스트 항목이 정의됩니다. 이는 기획, 개발, 테스트가 동일한 결과물에 대해 공유하고 협업할 수 있게 해줍니다.

E2E 시나리오 양식 예시

해당 표의 핵심은 다음과 같습니다.

코드화, Depth, 시나리오 그룹

코드화는 요구사항 명세서나 테스트 케이스 문서와의 호환성을 고려하여 추가하였으며, 시나리오 그룹은 테스트 코드의 단위를 효과적으로 묶기 위해 정의되었습니다.

E2E 테스트에서 API는 제외

서버 상태와의 완벽한 일관성을 유지할 수 없어 API Mocking 방식이나 API 테스트를 제외하였습니다. 또한, API가 변경되는 경우 E2E 테스트도 수정되어야하는 관리적인 리소스를 고려하였습니다.

우리가 구축하는 E2E 테스트의 방향성은 모든 범위를 완벽하게 커버하는 것보다는 주로 사용자 동작/시나리오에 중점을 둔 테스트 방식을 채택하게 되었습니다.

그래서...

Part 1에서는 간단하게 E2E 테스트와 Playwight에 대한 간략한 내용을 다뤘습니다. Playwright에 관심이 있거나 활용하려는 분들에게 도움이 되었으면 합니다.

다음 시리즈에서는 실제 작성한 코드에 대해 설명할 예정입니다.