지금까지 우리는 서비스 기획, DDD 모델링, 화면 기획, 인프라, 백엔드와 프론트 골격, 카탈로그, 인증, 장바구니, 주문, 결제, 운영자 화면, AI 상담 챗봇까지 단계적으로 만들었습니다. 이제부터는 각 기능이 따로 동작하는지보다, 하나의 이커머스 서비스로 이어지는지를 검증합니다.
이번 페이지의 목표는 테스트 도구 사용법을 나열하는 것이 아닙니다. 사용자가 실제로 상품을 사고, 운영자가 그 주문을 확인하고, 챗봇이 같은 주문과 상품 맥락을 안전하게 안내하는지 끝에서 끝까지 확인하는 시나리오를 만드는 것입니다.
즉 이번 장은 "기능이 구현되어 있다"를 "서비스로 믿고 실행할 수 있다"로 바꾸는 단계입니다.
단위 테스트와 API 테스트는 필요합니다. 하지만 풀스택 서비스에서는 그것만으로 충분하지 않습니다.
E2E 시나리오는 이런 연결 문제를 찾기 위한 검증입니다.
이 페이지를 읽고 나면 아래 항목이 정리되어 있어야 합니다.
E2E를 화면 목록대로 만들면 테스트가 많아 보이지만 실제 위험을 잘 잡지 못합니다. 이번 교재에서는 업무 흐름 기준으로 묶습니다.
이 흐름 하나가 통과하면 구매자, 백엔드, DB, admin, 챗봇 연결이 함께 검증됩니다.
E2E는 시작 상태가 안정적이어야 합니다. 매번 다른 데이터에서 시작하면 실패 원인을 판단하기 어렵습니다.
초기 seed는 아래 정도가 필요합니다.
테스트가 주문을 생성한다면, 실행 전 장바구니와 주문 데이터를 정리하거나 테스트 전용 사용자로 분리하는 것이 좋습니다.
첫 번째 핵심 시나리오는 정상 구매 흐름입니다.
검증 순서는 아래와 같습니다.
통과 기준은 단순히 화면이 넘어가는 것이 아닙니다. 주문 ID, 주문 상태, 결제 상태, 금액 합계가 예상과 일치해야 합니다.
두 번째 시나리오는 구매자가 만든 주문이 운영자 화면에 반영되는지 확인합니다.
검증 순서는 아래와 같습니다.
통과 기준은 storefront에서 생성한 주문과 admin에서 보는 주문이 같은 데이터라는 점입니다. 프론트별로 별도 mock 데이터를 쓰고 있으면 이 시나리오에서 바로 드러납니다.
세 번째 시나리오는 AI 상담 챗봇이 실제 주문 맥락을 안전하게 사용하는지 확인합니다.
검증 순서는 아래와 같습니다.
통과 기준은 챗봇이 근거 없는 일반 답변을 하지 않고, 현재 사용자의 주문 상태를 권한 검사 후 반영하는 것입니다.
챗봇과 admin을 붙이면 권한 검증이 더 중요해집니다.
검증 순서는 아래와 같습니다.
통과 기준은 백엔드가 권한을 막는 것입니다. 프론트 라우팅에서만 막는 것은 충분하지 않습니다.
상품 운영 도구가 있다면 admin 변경이 구매자 화면에 반영되는지도 검증해야 합니다.
검증 순서는 아래와 같습니다.
통과 기준은 현재 상품 상태와 과거 주문 snapshot이 분리되어 동작하는 것입니다.
성공 흐름만 검증하면 실제 서비스 품질을 알기 어렵습니다. 최소한 아래 실패 흐름은 포함합니다.
실패 흐름의 통과 기준은 "에러가 난다"가 아니라, 사용자가 다음 행동을 이해할 수 있어야 한다는 점입니다.
모든 시나리오를 처음부터 자동화할 필요는 없습니다. 하지만 반복될수록 위험한 흐름은 자동화해야 합니다.
자동화 우선순위는 아래 순서가 적절합니다.
챗봇은 LLM 응답이 변동될 수 있으므로, 답변 문장 전체보다 구조화 응답과 핵심 상태 포함 여부를 검증하는 편이 좋습니다.
프론트 E2E는 Playwright 같은 브라우저 테스트 도구가 적합합니다. 백엔드 API 흐름은 pytest 기반 통합 테스트로 검증할 수 있습니다.
이번 교재의 권장 구조는 아래와 같습니다.
중요한 것은 도구 이름이 아니라, 검증 대상이 겹치지 않게 역할을 나누는 것입니다.
모노레포에서는 테스트 위치도 명확히 해야 합니다.
예시 구조는 아래와 같습니다.
server/tests/integration: 백엔드 통합 테스트client/storefront/e2e: 구매자 E2Eclient/admin/e2e: 관리자 E2Etests/e2e: 여러 앱을 동시에 다루는 cross-app E2Esdd/03_verify: 사람이 읽는 검증 시나리오와 결과 기록코드로 실행되는 테스트와 사람이 읽는 검증 기록을 섞지 않는 것이 좋습니다.
E2E는 통과/실패만으로 끝내지 말고, 무엇을 봤는지 남겨야 합니다.
각 시나리오는 아래 항목을 기록합니다.
이 기록이 있어야 다음 사람이 실패를 재현할 수 있습니다.
이번 장에서 완료라고 볼 수 있는 상태는 아래 정도입니다.
즉 이제 기능별 개발이 아니라 제품 단위 검증으로 넘어갈 준비가 된 상태입니다.
이번 페이지를 코드와 실행 결과로 옮기면 최소한 아래 산출물이 있어야 합니다.
이 산출물이 있어야 다음 페이지에서 성능, 보안, 권한 점검을 더 좁고 정확하게 수행할 수 있습니다.
이 일곱 가지 실수는 테스트가 있어도 실제 제품 품질을 보장하지 못하게 만듭니다.
이번 페이지에서는 구매자, 관리자, AI 상담 챗봇을 하나의 이커머스 서비스 흐름으로 검증하는 E2E 시나리오를 정리했습니다. 핵심은 화면별 테스트가 아니라, 주문이 생성되고 운영자 화면에 반영되며 챗봇이 같은 맥락을 안전하게 설명하는지 확인하는 것입니다.
다음 페이지에서는 성능과 보안과 권한을 점검합니다.