돌아보기: 테스트 자동화의 진화

Jecelyn Yeen
Jecelyn Yeen
Maksim Sadym
Maksim Sadym

테스트 자동화의 탄생

웹브라우저가 탄생한 1990년대로 돌아가 보겠습니다. 테스트 자동화는 2000년대 Selenium 및 WebDriver 프로젝트가 등장하여 교차 브라우저 및 멀티기기 테스트 문제를 해결하면서 현실화되었습니다.

이 두 프로젝트는 2011년에 Selenium WebDriver로 합병되었으며 2018년에 W3C 표준이 되었습니다. 일반적으로 WebDriver 또는 WebDriver '기존'이라고 합니다.

Selenium WebDriver 프로젝트의 진화
Selenium WebDriver 프로젝트의 발전

WebDriver '기존' 이전의 테스트 자동화는 매우 까다로웠습니다. 브라우저 테스트를 자동화할 수 있게 되면서 개발자와 테스터의 삶의 질이 크게 개선되었습니다.

JavaScript의 부상

웹 개발이 JavaScript를 더 많이 사용하도록 발전함에 따라 WebdriverIO, Appium, Nightwatch, Protractor (지원 중단됨), Testcafe, Cypress, Puppeteer, Playwright와 같은 새로운 자동화 솔루션이 등장했습니다.

JavaScript 자동화 도구
JavaScript 자동화 도구

자동화 접근 방식

이러한 도구는 브라우저를 자동화하는 방식에 따라 크게 두 가지 그룹으로 분류할 수 있습니다.

  • 고급: 브라우저 내에서 JavaScript를 실행하는 도구입니다. 예를 들어 Cypress 및 TestCafe는 웹 API와 Node.js를 활용하여 브라우저에서 직접 테스트를 실행합니다. 재미있는 사실은 Selenium의 첫 번째 버전에서도 동일한 접근 방식을 사용했다는 점입니다.
  • 하위 수준: 브라우저 외부에서 원격 명령어를 실행하는 도구입니다. 도구에 여러 탭을 열거나 기기 모드를 시뮬레이션하는 등 더 많은 제어가 필요한 경우 프로토콜을 통해 브라우저를 제어하기 위해 원격 명령어를 실행해야 합니다. 두 가지 주요 자동화 프로토콜은 WebDriver '기존'과 Chrome DevTools 프로토콜 (CDP)입니다.

다음 섹션에서는 이러한 두 프로토콜을 살펴보고 각 프로토콜의 장점과 한계를 알아봅니다.

WebDriver Classic 및 CDP

WebDriver '기존'과 Chrome DevTools 프로토콜 (CDP) 비교

WebDriver '기존'은 모든 주요 브라우저에서 지원되는 웹 표준입니다. 자동화 스크립트는 HTTP 요청을 통해 드라이버 서버에 명령어를 실행하고, 드라이버 서버는 내부 브라우저별 프로토콜을 통해 브라우저와 통신합니다.

교차 브라우저 지원이 뛰어나고 API가 테스트용으로 설계되었지만 속도가 느릴 수 있으며 일부 하위 수준 컨트롤은 지원하지 않습니다.

WebDriver '기존'
WebDriver '기존'

예를 들어 요소 await coffee.click();를 클릭하는 테스트 스크립트가 있다고 가정해 보겠습니다. 일련의 HTTP 요청으로 변환됩니다.

# WebDriver: Click on a coffee element

curl -X POST http://127.0.0.1:4444/session/:element_id/element/click
   -H 'Content-Type: application/json'
   -d '{}'

반면 Chrome DevTools 프로토콜 (CDP)은 처음에 Chrome DevTools 및 디버깅을 위해 설계되었지만 자동화를 위해 Puppeteer에서 채택되었습니다. CDP는 WebSocket 연결을 통해 Chromium 기반 브라우저와 직접 통신하여 더 빠른 성능과 하위 수준 제어를 제공합니다.

하지만 Chromium 기반 브라우저에서만 작동하며 개방형 표준이 아닙니다. 게다가 CDP API는 비교적 복잡합니다. 경우에 따라 CDP를 사용하는 것이 인체공학적이지 않을 수 있습니다. 예를 들어 프로세스 외부 iframe을 사용하면 많은 노력이 필요합니다.

CDP
Chrome DevTools 프로토콜

예를 들어 요소 await coffee.click();를 클릭하면 일련의 CDP 명령어로 변환됩니다.

// CDP: Click on a coffee element

// Mouse pressed
{ 
  command: 'Input.dispatchMouseEvent', 
  parameters: {
    type: 'mousePressed', x: 10.34, y: 27.1, clickCount: 1 }
}

// Mouse released
{ 
  command: 'Input.dispatchMouseEvent', 
  parameters: {
    type: 'mouseReleased', x: 10.34, y: 27.1, clickCount: 1 }
}

하위 컨트롤이란 무엇인가요?

WebDriver '기존'이 개발된 시절에는 하위 수준 제어가 필요하지 않았습니다. 하지만 시대가 변했고 웹의 기능이 훨씬 향상되었으며, 오늘날 테스트에는 더 세부적인 작업이 필요합니다.

CDP는 모든 디버깅 요구사항을 충족하도록 설계되었으므로 WebDriver '기존'에 비해 더 많은 하위 수준 컨트롤을 지원합니다. 다음과 같은 기능을 처리할 수 있습니다.

  • 콘솔 메시지 캡처
  • 네트워크 요청 가로채기
  • 기기 모드 시뮬레이션
  • 위치정보 시뮬레이션
  • 그 외에��� ������한 ���능 제공

WebDriver '기존'에서는 아키텍처가 다르기 때문에 이러한 작업이 불가능했습니다. WebDriver '기존'은 HTTP 기반이므로 브라우저 이벤트를 구독하고 수신 대기하기가 까다롭습니다. 반면 CDP는 WebSocket 기반이며 기본적으로 양방향 메시지를 지원합니다.

다음 단계: WebDriver BiDi

다음은 WebDriver '기존'과 CDP의 장점을 요약한 것입니다.

WebDriver '기존' Chrome DevTools 프로토콜 (CDP)
최고의 교차 브라우저 지원 빠른 양방향 메시지
W3C 표준 하위 수준 제어 제공
테스트용으로 빌드됨

WebDriver BiDi는 WebDriver '기존'과 CDP의 장점을 결합하는 것을 목표로 합니다. 현재 개발 중인 새로운 표준 브라우저 자동화 프로토콜입니다.

WebDriver BiDi 프로젝트의 작동 방식, 비전, 표준화 프로세스에 대해 자세히 알아보세요.