E2E Test 알아보기

Changhoon Hyun
HBsmith
Published in
7 min readJan 7, 2019

--

https://www.bcdtravel.com/move-be/correcting-the-end-to-end-disconnect/

안녕하세요. HBSmith 개발자 현창훈 입니다. 요즘 저희가 E2E 관련 서비스를 개발중인데 아직 E2E Test를 잘 모르거나 Test Code는 백엔드에서만 작성하는 것이라고 생각하시는 분들이 많은것 같아서 E2E Test 소개 글을 작성해봤습니다.

E2E Test란(End To End Test)

E2E Test는 종단(Endpoint) 간 테스트로 사용자의 입장에서 테스트 하는 것 입니다. 보통 Web, App 등에서 GUI를 통해서 시나리오, 기능 테스트 등을 수행합니다. 사용자에게 직접 노출되는 부분을 점검한다고 생각하시면 될 것 같습니다. 저는 웹 서비스를 주로 개발했기 때문에 본 글에서는 웹 환경을 기준으로 작성하겠습니다.

프론트엔드와 백엔드의 테스트

요즘 더욱 테스트의 자동화에 관심을 가지는 분들이 많습니다. 먼저 프론트엔드, 백엔드로 구분해서 테스트에 대해서 간단히 설명하겠습니다.

  • 프론트엔드: 원하는 Text가 제대로 나오는지, A를 클릭했을 때 기대하는 동작을 하는지 등을 테스트 합니다. 작은 수정에도 테스트가 깨지기 쉽고 Mock Injection해서 UI만 테스트 하는것도 공수가 많이 들어갑니다.
  • 백엔드: API, Function 등에 Mock을 Injection 하고 기대하는 값을 Return 하는지 확인합니다. 난이도와 공수가 낮아서 TDD까지는 아니더라도 일부 Business Logic을 Unit Test 혹은 Scenario Test를 작성해서 관리하시는 분들이 많습니다.

왜 E2E Test를 해야하는가

1. QA가 제품관리를 잘 할 수 있게 도와주세요.

  • 프론트엔드와 백엔드에서 열심히 테스트 코드를 작성하고 높은 Coverage를 유지해도 통합하면 문제가 발생하는 경우가 많습니다. 이 부분에서 발생하는 문제들은 사용자들에게 그대로 노출되고 부정적인 이미지를 줄 수 있기 때문에 제품 관리 측면에서 예민하게 반응할 수 밖에 없습니다. 그래서 QA에서 시스템 테스트를 진행합니다. 하지만 단순, 반복적인 테스트를 항상 진행하는것은 현실적인 어려움이 있습니다. 이런 영역들을 자동화 해서 제품 관리자들이 더 의미있는 일을 하게 해주는것이 중요합니다.
  • E2E Test를 하면 사용자의 동작을 모사해야 하기 때문에 사용자 입장의 Workflow와 Laytency를 측정하고 점검할 수 있습니다. 자연스럽게 사용자의 경험을 더 고민하게 됩니다.

2. 테스트 코드를 작성할 공수가 제한적이라면 E2E만 하세요.

  • 프론트엔드, 백엔드, E2E 모든 영역에서 테스트 코드를 작성 하면 좋겠지만 그 정도의 공수를 투입하는것은 현실적으로 힘든 일입니다. 만약 하나만 골라서 제대로 해야 한다면 저는 E2E만 테스트 코드를 작성 하겠습니다. 종단(EndPoint)에서 테스트를 통과하면 기능이 잘 작동하는 것이고 종단에서 실패하는 테스트가 진짜 문제입니다.

E2E Test Framework

Web 환경에서는 Selenium, Cypress, TestCafe 등이 있습니다. 이번에는 Cypress와 TestCafe에 대해서 소개하도록 하겠습니다.

Cypress

  • OpenSource Project(MIT License)
  • Browser Support: Electron, Chrome
  • Element 접근: Iframe에 Target Web을 올린 뒤 Browser 내부에서 접근함.
  • Headless Support: 지원
  • CLI Support: 지원
  • ScreenShot: 지원
  • Video Record: Electron만 지원
  • 심플한 API 제공
  • Mocha 기반이기 때문에 Nodejs 개발자들에게 익숙합니다.
  • 내부적으로 queue를 써서 sync인것 처럼 동작합니다.
describe('sample', function () {    it('run', () => {
cy.visit('https://hbsmith.io')
cy.get('#cotactName') .type('Test') .get('#contactEmail') .type('your-email') .get('#contactService') .type('hbsmith.io') .get('#bottom') .click() })})
Cypress의 화면

제약사항 / 단점

  • multi tab: 미지원
  • popup: 미지원
  • Cypress 내부 에러 핸들링이 쉽지 않다.
  • 완성도가 낮다.

TestCafe

  • OpenSource Project(MIT License)
  • Browser Support: Chrome, Safari, IE, Edge, FireFox, 기타 Mobile Web 등
  • Element 접근: Proxy를 통해서 Target Web에 접근함.
  • Headless Support: 지원
  • CLI Support: 지원
  • ScreenShot: 지원
  • Video Record: 미지원
  • 유연한 Selector, Action API 제공
  • 직접 Async / Await을 통한 관리
  • try catch 구문을 이용한 에러 핸들링 가능
  • DevExpress에서 TestCafe를 위한 전용 IDE 지원(Preview)
fixture `New Fixture`    .page `https://hbsmith.io/`;test('New Test', async t => {    await t        .typeText(Selector('#cotactName'), 'Test')        .typeText(Selector('#contactEmail'), 'your-email')        .typeText(Selector('#contactService'), 'app.hbsmith.io')        .click(Selector('#bottom').find('.btn.btn-success.btn-lg'));});

제약사항 / 단점

  • multi tab: 미지원
  • popup: 미지원
  • 복잡한 웹에서는 간단한 구문도 깨지는 경우가 많다. 완성도가 너무 낮다.

Cypress vs TestCafe

  • 안정성: 둘 다 잔버그가 있지만 Cypress가 좀 더 안정적인것 같습니다.
  • 브라우저 지원: 크로스 브라우저 테스트는 웹 서비스를 하는 모든곳의 과제입니다. TestCafe는 다양한 브라우저를 지원합니다.
  • 러닝 커브: Cypress의 API가 더 단순해서 배우기 쉽습니다.
  • 프로젝트 지속성: 둘 다 오픈소스 프로젝트 입니다. 현재는 Cypress가 더 활발히 진행중입니다.
Cypress의 Insights
TestCafe의 Insights

둘 중 선택해야 한다면 저는 안정성이 더 높은 Cypress를 선택 하겠습니다. 지원하는 브라우저가 제한적이지만 안정적으로 자동화 테스트를 지원하는게 중요하다고 생각하기 때문입니다.

HBSmith는 자동화, 테스트에 대한 관심이 많습니다. 앞으로도 관련 내용을 꾸준히 공유하도록 하겠습니다. 감사합니다.

--

--