E2E 테스트 도입 경험기

카카오엔터테인먼트 FE 그룹이 프로젝트에 E2E 테스트를 도입하며, 도입 자체보다 꾸준히 운영하는 쪽에 초점을 맞춰 정리한 글이다. 유닛 테스트와 달리 성공적인 E2E 운영 사례를 찾기 어려웠던 이유를 걸림돌 세 가지로 정리하고, 각각에 대응하는 원칙을 세워 적용했다.

핵심 포인트

E2E 테스트는 사용자 시나리오로 애플리케이션 동작의 무결성을 검증한다. 모듈의 무결성을 증명하는 유닛 테스트로는 거기까지 닿지 못한다.
테스트 피라미드는 비용에 따라 E2E 10퍼센트, 통합 30퍼센트, 유닛 60퍼센트 비중을 제안한다. 비중 이론은 여럿이지만 E2E 는 꼭 필요한 것만 해야 한다는 데는 이견이 적다.
설치는 쉽다. Cypress 는 개발 의존성으로 설치하는 명령 한 줄이면 기본 설정 파일이 생성되고 runner GUI 가 뜬다.
걸림돌 첫째는 QA 팀 업무와 겹친다는 점이다. 협의 없이 개발자가 시나리오를 짜면 QA 가 더 넓은 범위를 중복 검증하게 돼 효용에 의문이 생긴다.
걸림돌 둘째는 관리 비용, 셋째는 속도다. 하나에 6초씩 100개 시나리오면 10분이 걸리는데 Cypress 는 병렬 테스트를 유료 플랜에서만 지원한다.

상세 정리

유지보수 단계에 들어간 프로젝트는 최소 인원만 투입돼 코드 수정에 집중하게 되고, 가벼운 테스트도 관리가 어려운 마당에 E2E 는 더 밀린다.
husky 나 GitHub Actions 로 통과해야 병합되게 강제하면 고치긴 하겠지만, 억지로 관리되는 테스트는 의미가 퇴색되고 시간만 잡아먹는다고 지적한다.
Cypress 유료 플랜은 Business 기준 월 300달러에 테스트 1만 개 제한이며, 병렬 실행 외에 대시보드와 GitHub 연동도 함께 제공된다.
결국 QA 팀 협업은 역량과 경험이 부족해 다음 프로젝트로 미루고, 개발 중인 프로젝트라 도입 시기가 좋다는 판단으로 시작했다.
원칙 1은 시나리오를 기획서에 정의된 동작을 옮겨 적는 것으로 정한 것이다. QA 팀도 기획서 기준으로 검증하므로 시나리오가 가까워진다.
이 원칙은 관리 문제도 함께 푼다. 새 기능이나 수정이 생기면 기획서가 바뀌고, 그 시점에 시나리오도 같이 고치면 최신 상태가 유지된다.
원칙 2는 Mock 데이터를 쓰지 않고 실제 API 만 쓰는 것이다. Mock 으로 만든 시나리오는 늘 개발자가 원하는 대로 흘러가 신뢰성을 떨어뜨린다.
백엔드 오류나 잘못된 응답값을 잡으려면 응답을 가로채 바꾸지 말아야 한다. 실제 API 를 쓸 수 없다면 QA 팀에 위임하거나 그 모듈만 통합 테스트로 검증한다.
원칙 3은 husky 의 pre-push 단계에서 E2E 를 통과한 코드만 push 되게 한 것이다. GitHub Actions 도 좋지만 개발 환경 접근 IP 가 제한돼 있어 husky 를 골랐다.
원칙 4는 속도 보완이다. Sorry-Cypress 의 도커 이미지를 로컬에 띄우고 테스트 프로세스를 여러 개 동시에 실행하면, 같은 id 로 실행된 테스트를 서버가 중복 없이 분배한다.
그 결과 2분 이상 걸리던 테스트가 30초대로 줄었고, 필요하면 프로세스를 늘리면 된다. 자체 서버를 띄우거나 대시보드를 운영할 수도 있다.

왜 읽나E2E 테스트를 붙였다가 관리 부담에 걷어낸 경험이 있거나 도입을 망설이는 팀에게, 실패 요인을 먼저 나열하고 각각에 대응하는 운영 원칙을 제시하는 글.

카카오 엔터테인먼트 FE 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청

E2E 테스트 도입 경험기

이 글과 비슷한

토스는 어떻게 광고 속에 게임을 넣었을까

RxJS로 우아하게 사이드 이펙트 통제하기

항공 프론트엔드 구축기 (7/10): 창구를 하나만 두었습니다