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

Jecelyn Yeen

Maksim Sadym

테스트 자동화의 탄생

웹브라우저가 태어난 1990년대로 돌아가 봅시다. 테스트 자동화는 2000년대가 되어서야 교차 브라우저 및 다중 기기 테스트 문제를 해결하기 위한 Selenium 및 WebDriver 프로젝트가 등장하면서 현실이 되지 않았습니다.

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

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

JavaScript의 부상

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

자동화 방식

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

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

다음 섹션에서는 이 두 가지 프로토콜을 살펴보고 각각의 강점과 한계를 살펴보겠습니다.

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

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

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

예를 들어 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을 사용하려면 많은 노력이 필요합니다.

예를 들어 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 'Classic'이 개발되었을 때는 하위 수준의 제어가 필요하지 않았습니다. 하지만 시대가 변화했고, 이제 웹은 훨씬 더 많은 기능을 사용할 수 있게 되었고, 오늘날의 테스트에는 더 세분화된 작업이 필요합니다.

CDP는 모든 디버깅 요구사항을 처리하도록 설계되었기 때문에 'Classic' WebDriver보다 더 낮은 수준의 제어를 지원합니다. 다음과 같은 기능을 처리할 수 있습니다.

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

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

다음 단계: WebDriver BiDi

다음은 WebDriver 'Classic'과 CDP의 강점을 요약한 것입니다.

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

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