이 글은 'E2E 테스트 도구(tool)들 분류하기'에 이은 3번째 연재물입니다. 앞서 분류했던 Progressive automation과 Test runner 영역에서 각각의 도구를 선택했습니다. 이때 선택의 기준을 세우고 그 기준에 맞게끔 선택을 했는데요. 그 선택 과정을 정리해 본 글입니다.
목차
- 무엇을 선택했는가?
- 왜 선택했는가?
- 성능
- 다양한 브라우저 지원
- 병렬처리
- 멀티 Tab 지원
- 왜 Cucumber는 선택하지 않았나?
- 마무리
연재물
- 테스트도 종류가 있다.(링크)
- E2E 테스트 도구(tool)들 분류하기.(링크)
- E2E 테스트로 왜 Playwirght 선택했는가?(링크)
- Playwright, Auth 자동화와 API Mocking(링크)
Playwright 빌드 자동화 구축(링크)VScode를 활용한 Playwright(링크)
무엇을 선택했는가?
웹서비스인 직방 파트너스웹에 e2e 테스트를 붙이는 작업을 진행한 바 있습니다. 아래의 4가지 사항을 두고 고민했고,
- Cypress
- Cypress + Cucumber
- Playwright
- Playwright + Cucumber
최종적으로는 Playwright 로 E2E 테스트환경을 구축하기로 결정했습니다.
왜 선택했는가?
먼저 Playwright와 Cypress의 간단한 비교를 해보겠습니다.
위와 같이 고려사항은 여러 가지가 있겠지만, 아래 3가지가 framework를 선택하는데 영향을 미쳤습니다.
- 성능
- 다양한 브라우저 지원
- 병렬처리
- 멀티 Tab 지원
성능
성능은 동일한 테스트 코드를 작성했을 시, 가벼운 테스트에서는 체감되지 않지만 테스트 코드가 늘어날수록 테스트 속도의 차이가 체감이 됩니다.
" 성능은 playwright 가 더 빠릅니다. "
왜? playwright가 더 빠른 걸까요?
여러 요소가 있겠지만, 그중에서도 테스트 실행 방식에 의해 나는 차이라고 생각합니다.
Playwright
✅ playwright는 webSocket 기반의 Event-Driven 방식으로 데이터를 주고받습니다.
Cypress
✅ Cypress는 동일한 이벤트 루프에서 테스트코드(one iframe)와 애플리케이션(another iframe)이 실행됩니다. 덕분에 실제 브라우저 API에 직접 접근할 수 있습니다.
위 내용을 봤을 때,
🙋♀️ 질문!
‘실제 브라우저 안에서 iframe을 통해 직접 브라우저 API에 접근하는 Cypress가 더 빨라야 하는 거 아니야?’
라고 생각하실 수도 있습니다. 하지만 playwright와 달리 cypress의 테스트는 실제브라우저를 띄우고 그 내부에서 실행됩니다. 브라우저가 동작한다는 것은 CPU, Memory 등등의 꽤 많은 컴퓨팅 자원을 요구합니다.
물론 headless 설정이 있습니다. 하지만 그래도 여전히 브라우저라는 것이 문제입니다. 여전히 추가적인 자원을 요구하게 될 거예요.
반면, playwright의 기본 설정은
일단 headless 기반이고요. CDP(chrome devtool protocol)을 사용하여 브라우저 테스트를 합니다. 음식으로 치자면 기본 설정부터가 기름기를 쫙 뺀 상태인 겁니다.
거기에 websocket까지 달았으니, 빠를 수밖에 없겠죠.
다양한 브라우저 지원
각 framework가 자동화 방식에 따라서 다양한 브라우저 지원이 쉽고, 어려운지가 결정되는 걸로 보입니다.
아래의 그림을 보면 단번에 이해가 될 것입니다.
앞서 봤듯이 Cypress는 browser 내부에서 테스트 코드를 실행시키는 구조입니다. 브라우저와 강하게 연결되어 있겠죠.
반면에, selenium은
많은 브라우저와 호환됩니다. webdriver 만 갈아 끼우면 되도록 유연한 구조를 가지고 있습니다.
그 중간 정도인 Playwright는
CDP(chrome devtool protocol) 활용하고 있고, Edge, Firefox, Webkit 등등의 브라우저에서는 CDP와 유사한 구현체를 가지고 있습니다.
덕분에 Cypress 보다는 더 다양한 브라우저를 지원하고 있습니다.
물론, Cypress도 playwright처럼 CDP 가 내장 되어 있다고 합니다. 하지만 기본 실행방식이 아니며, 추가적인 작업이 필요합니다.(링크)
또한 초기에는 Cypress는 chrome 브라우저만 지원 했었습니다. 하지만 Cypress 도 이제 Edge, Firefox 까지는 지원이 되는걸로 보입니다.
병렬처리
playwright는 테스트 병렬처리 기능을 무료로 제공해주고 있습니다. 하지만 Cypress 는 이 병렬 처리가 유료기능입니다. 물론 Sorry-Cypress (링크)라는 테스트 플러그인을 함께 쓰면, Cypress 도 병렬처리가 가능해진다고 합니다. 하지만 외부 플러그인을 끼워 쓰는 만큼 번거로운 설정을 해야 합니다.
반면 playwright는 playwright.config.js 파일에 worker 갯수만 설정해주면, 병렬로 테스트 작업을 처리합니다.
playwright.config.ts
import { defineConfig } from '@playwright/test';
export default defineConfig({
// Limit the number of workers on CI, use default locally
workers: process.env.CI ? 2 : undefined,
});
멀티 Tab 지원
playwright 는 멀티 Tab 테스트 기능을 지원해 줍니다.(링크) 테스트를 적용하고자 하는 웹서비스에 Tab이 새로 생성되는 기능이 곳곳에 있습니다. 이 시나리오를 완벽히 커버하기 위해 멀티 Tab 지원은 필요한 기능이었습니다.
Cypress는 멀티 Tabs 기능을 지원하지 않습니다. (링크) 그 이유는 굳이 멀티탭이 열고 테스트를 할게 아니라, '시나리오를 분리해서 각각 테스트하라' 것이 공식문서의 내용입니다.
물론 Cypress 의 방향도 틀린건 아닙니다. 테스트를 꼭 연결해서 할필요는 없습니다.
Cucumber는 왜 선택하지 않았나?
Playwright에 Cucumber 적용하는 방향도 고려를 했었지만, 결국 playwright 만 사용하기로 결정했습니다. Playwright는 내부적으로 Jest, Mocha, Jasmine 등등의 Test Runner를 제공합니다.
하지만 이번에 동료분의 추천을 통해 cucumber라는 놈을 알게 됐습니다. cucumber의 사용 예제만 봐도 명확했습니다.
- 테스트 코드 품질 관리나 테스트 시나리오 관리하기 좋음
- 시나리오는 feature, 테스트 코드는 step 이라는 개념으로 관리 되는데, 이 둘은 테스트 데이터를 주고받을 수 있어서, 시나리오 중신의 테스트 코드가 구축 가능합니다.
- 개발자 뿐만 아니라 다른 이해관계자들도 쉽게 테스트 시나리오 파일을 작성하거나 협업할 수 있습니다.
등등의 이유로 접목해보고자 했습니다.
하지만 최종적으로 아래의 이유 때문에 적용하지 않기로 했습니다.
- playwright 와 통합하여 사용할 방법은 있고, 예제도 몇개 있습니다. 다만 이렇게 되면 cucumber 의 설정을 따르게 되어, playwright.config.js 의 설정이 무시됩니다. (링크)
- 테스트로 엮일 이해관계자가 없습니다.
- 러닝커브가 있고, 비숙련자는 코드 생산성이 낮을 것이라 예상됩니다.
Cypress 도 장점이 있다
저의 선택에 대한 근거를 부각하다 보니 Cypress는 좋은 선택이 아닌 것처럼 비칠 수 있지만, 그렇지 않습니다. 조직의 방향성과 상황, 목표에 맞는 framework를 사용하면 됩니다.
Cypress는
- 환경 셋팅이 편하고, 다양한 플러그인이 있습니다.
- 테스트 GUI가 잘 갖춰져 있습니다.
- 리포트가 잘 되어 있습니다.
- API 사용법이 직관적이고 간단합니다.
저는 Cypress를 한마디로 표현한다면, All in One이라고 정의 내릴 수 있을 것 같습니다. 가장 커뮤니티가 활발한 프레임워크라서 설령 내부적인 지원이 안 되는 기능도 다양한 플러그인을 통해서 구축이 가능합니다.
마무리
지금까지 Playwrgiht를 선택하기까지 검토했던 내용을 정리해 봤습니다. 개인적으로 추후에 한번 더 시도해보고 싶은 것은 Cucumber와 playwright를 다시 한번 더 연동해 보는 겁니다.
물론 이미 이 둘을 연동하는 깃헙레포 (링크)도 있고, 미디엄 글 (링크)도 있습니다. 하지만 개인적으로는 위에서 언급했듯이
- playwright.config.js의 설정이 무시되는 점 (링크)
- cucumber의 실행주기가 있고, playwright의 실행주기가 있는데 이 둘의 타이밍이 제어에 대해 어려움이 있었다는 점
이 있어서, 더 문제를 해결해 가기보다는 빠르게 포기를 했습니다. 혹시 이에 대해 잘 아시는 분이나 경험이 있으시다면 함께 공유해 주시면 성장에 큰 도움이 될 것 같습니다.
번외로
playwright는 MS에서 지원하는 프로젝트인데요. 실제로는 Google에서 지원하는 puppeteer 프로젝트의 팀이 MS로 넘어와서 구축한 프로젝트라고 합니다.
아래는 관련 글(링크)에서 발췌한 내용입니다.
It is also good to mention here that playwright is an advance version of Puppeteer. Puppeteer, an open source web automation tool built by Google. However, Puppeteer did not offer support for Safari or Firefox. Microsoft hired developers from the Puppeteer team to build Playwright as an advanced version of that tool that provided more features and broader browser support.
'Dev.' 카테고리의 다른 글
| Playwright, Auth 자동화와 API Mocking (0) | 2023.06.13 |
|---|---|
| 테스트도 전략이다 (0) | 2023.05.27 |
| E2E 테스트 도구(tool)들 분류하기 (0) | 2023.05.27 |
| 내부에 개발자가 필요한 이유, 리팩터링 (0) | 2023.05.27 |
| [실전] 프론트 기존 컴포넌트를 개선한 경험 공유 (0) | 2023.05.27 |
