E2E Testing: Playwright 도입기 (with Travis CI)
작성 배경
E2E 테스트 도구 중 Playwright를 선택하게 된 이유와 배경, 직접 프로젝트에 적용해보면서 느꼈던 점을 기록으로 남기고자 작성하였습니다.
E2E 도입 계기
- Tapjoy는 특정 형식의 비디오 광고를 재생할 수 있는 클라이언트 제품이 있습니다. 무료 모바일 게임을 플레이하면서 게임 재화나 보상을 얻기 위해 광고를 시청해야 하는데 비디오 광고가 원활히 동작할 수 있도록, 그리고 유저가 정상적으로 보상을 받을 수 있도록 지원하는 플레이어입니다.
- 광고 플레이어는 모바일 웹뷰 환경에서 React로 동작하며, 내부적으로 광고 출력을 위해 광고 정보가 담겨있는 특정한 XML 획득하여 자바스크립트 플레이어가 이해할 수 있도록 Parsing하는 과정을 거치고 있습니다. Parsing하는 과정은 한가지의 모듈로 동작하는데, 해당 모듈은 Parsing 뿐만 아니라 다양한 역할을 하는 세부 모듈로 구성되어 있으며 그 중 게임 플레이어가 정상적으로 광고를 시청했는지, 혹은 클릭이 정상적으로 되었는지 등의 검증을 위한 Tracking 과정도 포함되어 있습니다.
- 모듈 업데이트가 빈번함에 따라, 모듈의 안정성에 대한 주제가 대두되었습니다. Parsing 부분은 유닛 테스트를 통해 충분히 이루어지고 있었지만, Tracking 과정은 유닛 테스트가 있으나 유저가 관여되는 부분이 있었기 때문에 유닛 테스트 만으로는 코드 안정성에 대한 검증이 다소 아쉬운 상태였습니다. 그래서 안정성 및 테스트 커버리지를 위해 유저 레벨에서 테스트 시나리오를 작성할 수 있는 E2E 테스트 도구를 적용하는 것으로 결정하고 여러 도구 중 Playwright 도입하게 되었습니다.
Playwright (극작가)
Playwright는 마이크로소프트에서 관리하는 E2E 테스트 도구이며 오픈소스 프로젝트입니다. Browser Manipulation의 대표적인 라이브러리 중 하나인 Puppeteer를 만들었던 팀이 담당하고 있습니다. 대표적으로 VSCODE의 E2E 테스트 도구로 활용되고 있으며 기존의 E2E 도구 사이에서는 비교적 최신임에도 불구하고 유명한 회사 및 프로젝트에서 활용되고 있습니다. Cypress와 같이 Non-Selenium(셀레니움 엔진을 사용하지 않는) 테스트 도구이며 Promise 기반의 자바스크립트로 작성 가능합니다.
(Selenium-wiki: https://en.wikipedia.org/wiki/Selenium_(software))
E2E 테스트 도구는 다양한 종류가 있지만 팀 내부적으로는 설치가 복잡하지 않으며, 테스트 구동이 빠르고, 자바스크립트 친화적인 Non-Selenium 기반의 도구로 결정하였습니다. 대표적으로 Cypress, Playwright, TestCafe 등이 있었습니다.
Cypress와 Playwright가 마지막 후보로 남게 되었는데 두가지 프레임워크의 각자의 특징과 장점이 분명하였기 때문에 선택의 어려움이 있었지만 iframe에 대한 원활한 지원이 필요했고 좀 더 현대적인 JS 문법으로 작성할 수 있다는 점이 주목받아 Playwright를 선택하게 되었습니다. 여러 특징을 아래에 간략히 추려보았습니다.
- Playwright: Promise 기반 테스트, 현대적인 JS 문법, 병렬 테스트, Boilerplate 없음, iframe 지원, 멀티 브라우저/플랫폼 지원 등…
- Cypress: Run-time 기반 테스트, 규모있는 커뮤니티와 많은 정보, 유저 친화적인 문서화 등…
사용하면서 느낀점
기본적인 환경 설정이나 작성 방법은 공식 문서에 잘 정리되어 있습니다. 사용법에 대한 상세한 설명보다는 사용하면서 느낀 장단점 등을 중점으로 서술하겠습니다.
No More Bolierplate & Easy Configuration
Playwright는 환경 설정 파일 외에 bolierplate 코드가 없습니다. 패키지와 브라우저 엔진을 설치하고 E2E 구동을 위한 특정 폴더만 지정해주면 모든 설정은 완료됩니다. 주목할만한 점은 타입스크립트를 위해 별도의 작업이 필요 없었던 점입니다. 그저 지정 폴더에 ‘*.spec.ts’ 파일을 만들기만 하면 되었습니다.
Parallelism: 비디오 광고 Duration에 따른 테스트 시간 증가 문제
Playwright는 병렬 테스트를 쉽게 설정할 수 있습니다. Node의 Worker 기반으로 동작하며 테스트 유닛 단위로 병렬 처리 여부를 세세하게 설정할 수 있습니다. 또한 브라우저 단위로 병렬 테스트가 가능하며 이로 인해 테스트 시간을 획기적으로 줄일 수 있습니다.
특히 테스트 작성 과정에서 저희 제품에 병렬 처리는 정말 중요한 포인트가 되었습니다. 설계된 테스트 시나리오의 특성 상 광고 플레이어의 동작을 검증하기 때문에 샘플 비디오의 재생 시간에 대한 의존성이 존재하였습니다. 예를 들어 비디오 광고가 30초이고 테스트 유닛이 8개라면 총 30 * 8초의 시간이 소요됩니다. 즉, 테스트 유닛이 하나가 늘어날 때마다 30초가 증가하기 때문에 테스트 시간에 대한 소요가 상당히 커질 우려가 있었으나 병렬 처리가 이 문제를 해소해 주었습니다.
iframe 지원
테스트 과정에는 iframe 내부 element를 다루는 일이 필요했기 때문에 도구를 결정하는 과정에서 중요한 기준이 되었습니다. Cypress에서는 iframe selector를 공식적으로 지원하지 않기 때문에 추가적인 workaround가 필요합니다. 반면 Playwright는 공식 iframe selector가 있고 일반적인 selector를 사용하는 것과 같은 경험을 제공하여 테스트 시나리오를 구현함에 있어 큰 불편함을 느끼지 못하였습니다.
위의 예시는 One depth의 iframe을 보여주지만, 테스트 상황에 따라 iframe이 여러번 중첩되는 상황도 있었습니다. 여기서 Playwright의 selector는 가독성을 유지하는데 많은 도움이 되었습니다. (물론 Cypress chain을 Promise로 변환하여 async/await을 활용 할 수도 있겠지만, 이를 위해서는 직접 유틸을 구현하거나 별도의 라이브러리를 사용해야합니다.)
Fixtures, Page Object Model: 테스트 설정과 로직 추상화
Playwright에는 Fixture 컨셉을 기반으로 테스트를 작성할 수 있습니다. 기본 인자로 제공되는 ‘page’ 객체가 fixture 컨셉으로 적용되어 있으며 사용자 정의도 가능합니다. 해당 컨셉을 활용하면, 특정 테스트 시나리오에만 해당되는 설정을 실제 테스트 코드로부터 관심사 분리가 가능하고 각 테스트의 컨텍스트를 고립화 할 수 있습니다.
Playwright Test is based on the concept of test fixtures. Test fixtures are used to establish environment for each test, giving the test everything it needs and nothing else. Test fixtures are isolated between tests. With fixtures, you can group tests based on their meaning, instead of their common setup.
Page Obejct Model은 페이지의 각 동작에 대한 복잡한 로직을 추상화 할 수 있습니다. 적용 후 느낀 점은 코드 가독성과 재사용성의 향상에 많은 도움이 되었다는 점입니다.
Page Object Model is a common pattern that introduces abstractions over web app pages to simplify interactions with them in multiple tests. …
Web Server: 서버 구동 걱정 없는 테스트
E2E에서는 테스트가 정상적으로 동작하기 위해 테스트를 실행 할 때 마다 매번 서버가 켜져있는지 확인하거나, 혹은 서버와 테스트가 연속적으로 동작할 수 있도록 구성해줘야합니다. (e.g. 연속적인 명령을 위한 별도의 패키지 설치 등) 여기서 Playwright의 Web Server의 편의성은 진가를 발휘합니다.
위와 같이 환경 설정에서 간단하게 Web Server 설정할 수 있습니다. 이렇게 한번 설정 해두면, 로컬 서버의 작동 유무를 고려하거나 연속적 동작을 위한 별도의 패키지 설치가 불필요합니다. 특히 좋았던 점은 프로젝트에서 개발 서버를 이미 구동하고 있다면 Playwright가 체크하여 서버 구동은 생략하고 바로 테스트 단계로 진입하는 점이었습니다.
Continuous Integration: 성능 한계 및 Worker 조절
저희는 코드의 지속적 통합을 위해 Travis CI를 사용하고 있습니다. 자동화 동작에 대한 초기 세팅은 어렵지 않았습니다. 로컬 환경에서 작업하던 것처럼 Playwirght 전용 브라우저를 설치하고, ‘npm ci’ 을 진행한 뒤 테스트가 동작하도록 설정 해두면 테스트 자동화는 완료됩니다.
테스트 작성 초기에는 로컬, CI 환경에서 모두 테스트가 정상적으로 통과하였습니다. 하지만 작성 완료 후 로컬에서는 테스트가 문제 없이 통과했지만, CI에서 통과하지 못하는 문제가 있었습니다.
환경 차이로 인해 테스트가 실패했을 가능성이 매우 높았기 때문에 Travis와 관련된 설정 등을 조정해보았으나 해결되지 않았습니다. 그래서 테스트 그룹 중 실패하는 그룹의 특징을 검토하였고, 결과적으로 해당 그룹이 성능에 많은 영향을 미치는 것으로 가정/판단하여 하나의 그룹 테스트만 수행하도록 변경 후 다시 확인한 결과, CI 상에서 정상적으로 테스트 통과하는 것을 알 수 있었습니다.
이후 여러 테스트를 거친 결과, 성능에 영향을 주는 그룹은 병렬 처리를 해제하고 테스트 실행을 담당하는 Worker의 수를 조절하는 방식으로 테스트 실패 문제를 해결하였습니다. 결과적으로 CI에서는 로컬보다 조금 더 테스트 시간이 증가하는 문제가 남게 되었으나, 적어도 Worker 수를 환경에 따라 자유롭게 조정하여 최적의 테스트 환경을 구성할 수 있었습니다. 이러한 설정에 대한 유연성이 Playwright의 큰 장점으로 느껴졌습니다.
React Component Selector
Playwright는 React Component Selector를 지원합니다. React로 코드를 작성하다보면 id나 class가 없는 컴포넌트로 만들어지는 경우가 발생하는데 이러한 시점에 유용하게 사용할 수 있었습니다. 단, 현재 Expriement 단계이며 스크립트가 Minified 되지 않은 Dev 상태에서만 유효하다는 점은 유의해야합니다.
Watch Mode의 부재
Playwright는 강력한 기능들을 지원함에도 불구하고, 공교롭게도 Watch Mode(Live Mode)를 공식적으로 지원하지 않았습니다. Third-party를 이용하여 기능을 사용할 수 있으나 완벽하지 않았습니다. 지금까지 지원에 대한 계획은 없어 보입니다.(https://github.com/microsoft/playwright/issues/7035)
개선해야할 점, 그리고 마치며
Playwright 도입과 Travis 연동은 성공적으로 마무리 되었습니다. 하지만 기존 Travis 빌드 시간에서 1.5배 가량 늘어나 해당 부분은 개선이 필요한 상황으로 보입니다. 현재 전체 빌드 시간이 길지 않지만 앞으로 테스트 커버리지가 확대됨으로 야기될 수 있는 추가적인 빌드 시간 증가에 미리 대비하는 것이 좋을 것으로 판단하여 이 부분에 대한 개선 여부를 궁리 중입니다.
Playwright는 출시된 지 3년이 채 되지 않은 신규 프로젝트입니다. 짧은 역사를 가지고 있음에도 불구하고, E2E 테스트 작성 과정에서 기능의 부족함으로 인한 불편함은 크게 느끼지 못하였습니다. 도리어 쉽게 설정 가능한 병렬 테스트, 기본 설정의 단순함, 테스트 로직 추상화 등은 정말 매력적이었습니다. E2E Testing 도구의 도입을 고려하시는 분이 있다면 Playwright는 충분히 좋은 선택지가 될 수 있다고 말씀드리며 이상 글을 마칩니다.
