e2e 테스트를 대화형 테스트 및 시나리오 테스트로 분할

저는 지난 몇 달 동안 엔터프라이즈 프로젝트에서 e2e(end-to-end) 프런트 엔드 테스트에 직면했으며 프런트 엔드 테스트를 시작하기 전에 개발자가 주목할 만한 몇 가지 실용적인 팁을 찾았습니다. 이 게시물에서 그 중 하나를 공유하겠습니다.

e2e 테스트를 대화형 테스트 및 시나리오 테스트로 분할

대화형 테스트(또는 통합 테스트)는 모달 창 열기/닫기 및 입력 데이터 바인딩과 같은 특정 페이지 내의 동작 테스트를 의미합니다.

반면에 시나리오 테스트는 성공적인 페이지 전환과 페이지 간의 데이터 일관성을 보장합니다. 예를 들어, 구매 시나리오 테스트는 사용자가 들어간 Top 페이지에서 동일한 사용자가 종료하는 감사 페이지로 시작합니다.

첫 번째 이유: 불안정한 결과 피하기

이 두 테스트를 분할하는 데는 두 가지 주요 동기가 있습니다. 불안정한 결과를 피하고 SSR 및 CSR 페이지를 분리할 수 있습니다.

첫째, 대화형 테스트와 시나리오 테스트를 하나의 광범위한 테스트에 혼합하면 불안정한(불안정한) 동작을 피하는 것이 너무 어려울 것입니다.

일반적으로 시나리오 테스트는 페이지 전환 및 데이터 전송을 포함하기 때문에 대화형 테스트보다 취약한 경향이 있는 반면 대화형 테스트는 하나 또는 몇 개의 구성 요소만 포함합니다.

또한 일반적으로 시나리오 테스트가 안정적으로 통과되기 시작하는 것은 완료된 단계가 될 때까지입니다. 반대로 대화형 테스트는 개발자가 몇 가지 구성 요소 구현을 완료하는 즉시 통과되며 외부 데이터 및 웹 서비스에 덜 민감합니다.

두 번째 이유: 모의 데이터 vs. 실제 데이터

마지막으로 대화형 테스트는 모의 데이터를 사용하는 것이 좋습니다. 일반적인 경우와 에지 경우를 모두 포함하여 다양한 구성 요소 동작을 테스트하기를 원하기 때문입니다. 대부분의 e2e 테스트 프레임워크는 이러한 API 응답 가로채기를 지원합니다.
반면 시나리오 테스트는 데이터 일관성이 핵심 부분이므로 실제 API 데이터에 더 적합합니다.

대화식 테스트 → 모의 데이터

시나리오 테스트 → 실제 API 데이터

세 번째 이유: SSR과 CSR 페이지 분리

둘째, 특정 페이지 내 대화형 테스트는 SSR 동작을 테스트할 수 있는 반면 페이지 전체에 걸친 시나리오 테스트는 CSR 동작을 테스트할 수 있습니다. 개발자는 이러한 차이점을 모를 수 없습니다. 그렇지 않으면 테스트되지 않은 상황에서 런타임 동작이 실패합니다.

두 가지 유형의 테스트로 분리하면 이러한 테스트를 독립적으로 실행할 수 있고 예측 방식으로 e2e 테스트를 개발하고 테스트 실패의 원인을 분석할 수 있습니다.

테스트 디렉토리 구조
테스트 폴더에서 동일한 폴더 경로 및 파일 이름을 route/pages 폴더로 사용하는 것이 더 유지 관리하기 쉽습니다.

예를 들어 cypress/integrations/top.spec.js는 Top 페이지의 모든 대화형 사례를 테스트합니다.

그리고 대화식 테스트는 integrations 폴더 대신 interactive 폴더에 저장됩니다. Cypress에 기본적으로 이 폴더가 있기 때문입니다.

다음은 Cypress를 선택한 경우 샘플 폴더 디렉토리입니다.

cypress
 ├ integrations
 | ├ top.spec.js
 | ├ search.spec.js
 | ├ product.spec.js
 | ├ cart.spec.js
 | └ order.spec.js
 |
 ├ scenarios
 | ├ purchase
 | ├ inquiry
 | ├ cancellation 
 | └ content-reader
 |
 ├ plugins
 ├ fixtures
 └ others (downloads, screenshots, etc.)

그게 다야. 이 팁이 e2e 테스트를 계획하는 데 도움이 되기를 바랍니다.

감사!