Cypress를 이용한 E2E 테스트 도입

E2E 테스트 도입기

E2E(End-to-End) 테스트는 QA 담당자뿐만 아니라 개발자에게도 필수적인 테스트입니다. 자신이 개발한 기능이 제대로 작동하는지 확인함으로써 반복되는 작은 실수를 줄일 수 있습니다. 이로 인해 QA 단계에서의 비용을 절감하고, QA 단계에서는 보다 크리티컬한 문제에 집중할 수 있게 되어 결과적으로 제품 품질이 향상될 수 있습니다. 특히 여러 환경(OS)을 지원하는 제품의 경우, OS 마다 반복적인 웹 테스트가 필요하므로 자동화된 테스트를 구축하여 반복적으로 소모되는 시간을 줄일 수 있습니다. 이번 글에서는 젠킨스와 Cypress를 활용한 E2E 테스트 도입기를 소개하겠습니다.

• E2E 테스트란?

E2E(End To End) 테스트는 애플리케이션의 전체 흐름을 검증하는 테스트 방법론입니다. 이 테스트는 최종 사용자 관점에서 모든 기능이 제대로 동작하는지 확인하는 데 중점을 둡니다. 또한, 최종 사용자가 겪을 수 있는 문제를 미리 파악하여 예방할 수 있습니다. 유닛 테스트나 통합 테스트보다 포괄적인 범위의 테스트입니다. 따라서 E2E 테스트는 제품의 전반적인 품질 보증에 필요한 것으로 여겨집니다.

• Selenium에서 Cypress로

기존에는 팀내에서 각자 Selenium을 사용하여 E2E 테스트를 구축했었습니다. Selenium 을 선택했던 이유는 해당 툴이 오래된 만큼, 풍부한 레퍼런스와 다양한 프로그래밍 언어 지원 덕분에 유용하다고 판단했기 때문이었습니다.

그러나 Selenium 을 사용하여 테스트를 계속 확장시키는 것에 대한 고민이 생겼습니다. Selenium의 설치 복잡성과 웹 드라이버 업데이트에 따라 주기적으로 웹 드라이버를 관리해야 하는 유지 관리의 어려움이 있었기 때문입니다. 특히, 실행 속도가 느리고 리포트 및 스크린샷 기능을 위해 별도의 third-party 라이브러리를 설치해야 하는 점은 Selenium을 처음 사용하는 개발자들에게 진입 장벽이 되었습니다. 이에 팀 내에서 대체 E2E 테스트 도구를 찾자는 의견이 나왔고, Playwright, Cypress, Puppeteer 등의 옵션을 검토하였습니다. 비슷한 장단점이 있었지만, 이 중에서도 커뮤니티가 비교적 많이 활성화되어 있고 레퍼런스가 많은 Cypress를 선택하게 되었습니다.

Selenium과 Cypress 비교

• 젠킨스 + Cypress 구축 과정

개발자가 제품을 릴리즈하기 전 E2E 테스트를 위해 반복적으로 소모하는 시간을 최소화하는 것이 주된 목표였습니다. 이를 위해 여러 서버에서 제품을 설치하는 것 부터 웹 페이지에 제품을 등록하고 웹 테스트를 수행하는 것까지를 하나의 테스트 사이클로 정했습니다.

E2E 테스트를 자동화하기 위해 젠킨스와 Cypress를 이용하여 테스트를 구축했고, 먼저 테스트 시나리오를 작성했습니다. 젠킨스의 “MultiJob” 플러그인을 활용하여 테스트 시나리오를 기반으로 각 단계별로 “MultiJob Phase”를 나누었습니다. 단계 별로 차례대로 테스트를 실행시키기 위해 다음 단계를 실행시키기 위한 조건은 “Successful” 또는 “Completed”로 설정했습니다. 또한, 테스트 결과를 대시보드로 확인하기 위해서 Cypress의 대시보드 기능이 필요했지만, 이 기능은 유료라서 대체 도구로 Sorry-Cypress라는 오픈소스를 사용하여 구현했습니다.

• 도입 결과

젠킨스에서 E2E 테스트를 실행시키면 첫번째 단계에서 젠킨스가 원격으로 서버에 접속하여 각 서버에 제품을 초기화 및 설치합니다. 설치가 완료되면 다음 단계에서 Cypress 가 설치된 서버로 접속하여 이어지는 테스트 시나리오 별로 Cypress 를 실행시킵니다. 결과는 Sorry-Cypress가 제공하는 대시보드를 통해 한 눈으로 확인할 수 있었습니다. Cypress가 제공하는 스크린샷 기능을 넣어서 테스트가 실패일 경우에는 어떤 부분에서 실패했는지 디버깅할 수 있게 했습니다.

Sorry-Cypress의 대시보드

젠킨스로 제품 설치를 자동화하고 전반적인 E2E 테스트에 대한 결과는 대시보드를 통해 확인할 수 있어서 제품 릴리즈 때마다 여러 환경에서 테스트하며 반복적으로 소모되었던 시간을 크게 줄일 수 있었습니다.

• 적용시 주의점

로컬 PC에서는 테스트가 성공했음에도 불구하고 젠킨스에서 실행 시 오류가 발생하는 경우가 있었습니다. 이는 테스트 환경마다 DOM(Document Object Model) 로딩 시간이 상이하기 때문입니다.

그럴 때에는 문제 있는 부분에 cy.wait() 를 주어 명시적으로 로딩시간을 기다리도록 변경했습니다. 또한 프론트엔드 팀과의 협업이 중요했습니다. 특정 엘리먼트에 ID 같은 키 값을 부여해야 테스트 코드 작성이 용이하고, 프론트엔드가 업데이트 등으로 수정되어 DOM 형태가 변해도 유효성을 유지할 수 있기 때문입니다.

Cypress를 선택한 이유는 설치가 용이하고 제공되는 자체 API를 통해 테스트 코드를 쉽게 작성할 수 있다고 판단했기 때문입니다. 특히 브라우저 드라이버를 별도로 다운로드할 필요 없이 테스트 러너에서 직접 브라우저를 실행할 수 있어 편리했습니다.

그러나 대시보드 및 병렬 테스트는 유료 기능이라 젠킨스에 연결하여 대시보드로 확인하고 싶다면 유료 서비스를 도입하거나 Sorry-Cypress와 같은 대체 도구를 사용해야 했습니다. Sorry-Cypress는 오픈소스로 Cypress의 유료 버전이 수행하는 기능을 어느정도 대체할 수 있습니다. 단, Cypress 13 이상의 버전부터는 오픈소스와의 협업이 중단되었으므로 사용 시 12 이하 버전으로 낮춰야 합니다. (관련된 내용의 링크를 참고 바랍니다.)

따라서 구축할 때 초기 단계에서부터 대시보드나 병렬 테스트 기능을 고려한다면 해당 기능이 무료인 Playwright를 선택하는 것도 좋은 대안이 될 것입니다.

• 마치며

여러 시행착오를 거쳐 젠킨스와 Cypress를 활용하여 E2E 테스트를 수행할 수 있게 되었습니다. 이 도입으로 E2E 테스트의 일관성을 높여 휴먼 에러를 최소화할 수 있었습니다. 또한, 불필요한 개발자의 리소스를 줄이고, 개발자는 제품 역량 강화에 더 많은 시간을 투자할 수 있어 전체적인 제품 품질 향상에 기여할 수 있습니다. 이러한 점으로 미루어보면, E2E 테스트 도입은 고려해볼 만한 선택이라고 생각합니다.