E2E 테스트 도구(tool)들 분류하기

출처 - Anete Lusina 의 사진 in pixel

이 글은 '테스트도 종류가 있다'라는 글에 이은 3번째 연재물입니다. 회사에서 E2E를 도입하기 전에 '어떤 도구를 사용하느냐?'에 대한 결론을 내려야 했는데요. 그러려면 E2E에 활용할 수 있는 도구를 분류부터 하는 것이 필요했습니다. 이 글은 테스트 도구들이 어떻게 분류될 수 있는지 알아보겠습니다.

 

목차

• 종류가 이렇게 많아?
• Progressive automation framework
• Test runner
• Platform testing
• 마무리

연재물

• 테스트도 종류가 있다.(링크)
• E2E 테스트 도구(tool)들 분류하기.(링크)
• E2E 테스트로 왜 Playwirght 선택했는가?(링크)
• Playwright, Auth 자동화와 API Mocking(링크)
• Playwright 빌드 자동화 구축(링크)
• VScode를 활용한 Playwright(링크)

 

---

종류가 이렇게 많아?

이번에 회사에서 프로젝트를 진행하면서, 일부 웹 프로젝트에 E2E 환경을 구축하는 작업을 진행했습니다. QA 조직 인원이 감축되어서, 일부 웹서비스에서는 QA 품질을 크게 기대할 수 없는 상황이 되었습니다.

그래서 E2E 환경을 구축하여 테스트 자동화를 해보고자 했었습니다.

 

E2E 테스트를 진행한다고 했을 때, 꽤 많은 선택사항이 있다는 것을 이번 경험을 통해 알게 됐습니다. 도구 선택 시,아래의 기준으로 고려해 볼 수 있습니다.

 

• 테스트 자동화 방법
• 테스트 코드 문법
• 플랫폼

 

이 기준으로 테스트 도구 분류를 아래와 같이 해봤습니다. (구글링을 통해서 조각조각 정보를 취합하여 분류하였습니다)

 

각 분류된 도구들은 서로 통합해서 사용할 수도 있고 하나의 도구로만 구축할 수도 있습니다.

 

 

---

Progressive automation framework

먼저 테스트 자동화를 위한 프레임워크 들 부터 살펴보겠습니다

출처 - 자체 제작

selenium  VS.  cypress  VS.  playwright

입니다.

대표적인 프레임워크들입니다. 지금부터 각각의 프레임워크의 아키텍처를 통해 어떤 차이가 있는지 보겠습니다

 

 

Selenium 동작방식

BrowserDriver와 Local Server에 띄운 실제 Browser와 통신하여, 실제 Browser와의 상호작용을 통해 명령을 실행하고 테스트합니다.

1. Local Server에서 BrowserDriver 생성 그리고 실제 Browser 동작
2. JSON Wire기반의 JSON Wire Protocol로 BrowserDriver에 명령 전달
3. BrowserDriver는 명령에 따라 Selenium Script 를 사용해서, 실제 Browser 를 동작시킴
4. 동작 결과를 Selenium Client Library 에게 전달

장점

• 설계 하기에 유연하다
• 언어, 브라우저의 한계가 없다
• 클라우드 환경에 사용하기 좋다

단점

• 테스트 속도가 느리다
• 구축이 번거롭다

 

---

Cypress 동작방식

반면 Cypress는 브라우저 내부에서 명령을 직접 테스트 케이스를 실행합니다. 이를 통해 브라우저의 이벤트를 실시간으로 응답할 수 있습니다.

1. Cypress Server가 모든 모듈, 코드를 Webpack 으로 하나의 번들 js 로 번들링한다
2. 브라우저 실행 후 iframe 위에서 Cypress Client 가 실행되고, Cypress Server 와 데이터를 주고 받는다
3. Cypress Client는 Application 과 통신하면서 DOM, Window, LocalStorage 같은 객체들에 접근하여 테스트를 수행한다.

장점

• Cypress 는 All in One Package 이다. 그래서 구축과 사용이 쉽다.
• 빠르게 구축이 가능하다

단점

• 컴퓨팅 자원이 많이 든다.
• 테스트 속도가 느리다.

 

---

Playwright 동작방식

Playwright의 가장 큰 특징 중에 하나는 playwright의 client와 server 가 webSocket을 기반으로 통신을 한다는 것입니다.

1. client 는 다양한 언어를 지원하고 있으며, Test code를 Json 포멧으로 변환한다.
2. client 와 server 가 single webSocket 으로 연결되고 json 포멧으로 된 데이터를 실어 나른다.
3. Server 는 CDP (Chrome DevTools Protocol) 을 이용해서 브라우저와 통신한다. Firefox, Webkit 등등 의 브라우저들은 playwright 내부적으로 CDP와 유사하게 구현되어 있다.

장점

• 테스트 속도가 빠르다
• 다양한 언어, 브라우저가 지원된다.

단점

• webSocket 기반이라 클라우드 환경에서는 통신이 불안정할 수 있다

 

보다시피 각 아키텍처 구조가 다르기 때문에, 거기서 오는 장단점이 분명합니다. ‘왜 Playwright 선택했는가?’ 글에서는 Cypress와 Playwright의 장단점을 더 상세히 따져보겠습니다.

 

 

 

---

Test runner

이번에는 test runner를 보겠습니다. 말이 거창하지만 사실 실제 테스트코드의 문법을 담당하는 녀석들입니다. 가장 유명한 녀석들이 jest와 mocha입니다.

하지만 이번에 동료분의 추천을 통해 cucumber라는 녀석을 알게 됐습니다. 

 

Cucumber

Cucumber의 특징을 정리해 보자면 아래와 같습니다.

• 시나리오 기반의 테스트 도구 입니다.
• 테스트 코드 품질 관리나 테스트 시나리오 관리하기가 좋습니다.
• 시나리오는 feature, 테스트 코드는 step 이라는 개념으로 관리 되는데, 이 둘 은 테스트 데이터를 주고받을 수 있어서, 시나리오와 테스트가 연결된 형태로 구축이 가능합니다.

⌨️ 시나리오 예시

Feature: Is it Friday yet?
  Everybody wants to know when it's Friday
Scenario: Sunday isn't Friday
    Given today is Sunday
    When I ask whether it's Friday yet
    Then I should be told "Nope"

️⚙️ 테스트 코드 예시

const assert = require('assert');
const { Given, When, Then } = require('@cucumber/cucumber');

function isItFriday(today) {
  // We'll leave the implementation blank for now
}
Given('today is Sunday', function () {
  this.today = 'Sunday';
});

When('I ask whether its Friday yet', function () {
  this.actualAnswer = isItFriday(this.today);
});

Then('I should be told {string}', function (expectedAnswer) {
  assert.strictEqual(this.actualAnswer, expectedAnswer);
});

 

---

Jest, Mocha

반면 Jest와 Mocha는

• 코드 기반의 테스트 도구입니다.
• 사용법이 쉽고, 제공되는 API들도 학습하기 쉽습니다. 덕분에 개발 속도는 더 빠르게 진행될 수 있죠.
• E2E 뿐만아니라 단위(Unit)테스트, 통합(integration) 테스트 등등 다양한 범위에서 사용됩니다.

⌨️ 코드 예시

function sum(a, b) {
  return a + b;
}
module.exports = sum;

⚙️ 테스트 코드 예시

const sum = require('./sum');

test('adds 1 + 2 to equal 3', () => {
  expect(sum(1, 2)).toBe(3);
});

Test runner 도구들도 마찬가지로 어느 것 하나가 우위에 있다기보다는, 결국 개발 조직의 성향, 현재 상황 등을 고려하여 선택하는 것이 옳습니다.

 

 

 

---

Platform testing

마지막으로 platform testing라는 분류입니다. 대표적으로 Appium과 Selenium 이 있는데요. 이미 아시는 분들을 아시겠지만 이 두 도구의 가장 큰 차이는 바로 테스트를 하고자 하는 플랫폼입니다.

출처 - 자체 제작

• appium — Mobile, 데스크탑 테스트 자동화
• selenium — Wep 테스트 자동화

 

테스트하고자 하는 실제 디바이스가 ‘모바일이냐 Web 이냐’가 선택의 기준이 될 것 같습니다.

 

 

 

---

마무리

지금까지 E2E 테스트를 다루는 도구들을 분류해 봤고, 각 영역별 프레임워크가 어떤 장단점이 있는지 정리해 봤습니다. 생각보다 E2E 테스트를 구축하는 데 있어서 선택사항이 많습니다.

다만 E2E 테스트를 진행하고자 했을 때, 다양한 선택사항들이 있으며 테스트 전략에 맞게끔 도구를 선택해야 합니다.

 

그러기 위해서는 현재 조직이 원하는 바를 명확하게 해야겠죠.

 

선택사항이 많은 거 같아 혼란스러울 수도 있겠지만, 이 중에서도 단연 메인 영역은 Progressive automation framework입니다.

저 같은 경우는 고민 끝에 playwright를 선정해서 구축했는데요. 그 이유와 과정을 설명하는 ‘왜 Playwright 선택했는가?’(링크) 글에서 작성해 보겠습니다.

 

 

 

---

 

아래는 개발 커뮤니티 링크입니다. 들어오셔서 기술 정보, 트렌드 정보, 유료스터디, 무료스터디, 모각코 등등을 이용해 보세요.

⛺️ 스터디 캠프 커뮤니티