애플리케이션 개발에서 E2E 테스트 — 개념, 시나리오 및 도구

E2E 테스트란?

E2E 테스트(End-to-End)는 테스트가 시스템의 모든 구성 요소를 통해 사용자의 전체 경로를 실행하는 소프트웨어 검증 방법입니다. 모바일 앱의 일반적인 E2E 시나리오에는 앱 실행, 새 사용자 등록, 이메일 확인, 목표 작업 수행(주문하기, 메시지 보내기) 및 인터페이스에서 결과 확인이 포함됩니다. 각 단계는 스텁이나 목 없이 실제 구성 요소를 사용합니다.

E2E 테스트의 주요 장점은 클라이언트, 서버, 데이터베이스 및 타사 서비스 간의 상호 작용을 포함하여 시스템을 하나의 통합된 단위로 검증한다는 점입니다. E2E 테스트는 테스트 피라미드의 하위 수준에서는 발견할 수 없는 문제를 찾아냅니다: 클라이언트와 서버 간 데이터 형식 불일치, 실제 환경의 인증 오류, 결제 게이트웨이 통합 장애 등입니다.

World Quality Report 2023에 따르면, CI/CD 파이프라인에 E2E 테스트를 도입한 팀은 릴리스 시 치명적 결함 수를 45% 줄였습니다. 전체 E2E 테스트 수행 시간은 시나리오 수에 따라 20분에서 2시간까지 소요되므로, 병렬 실행 전략이 필요합니다.

E2E 테스트와 통합 테스트의 차이

주요 차이점은 검증 범위에 있습니다. 통합 테스트는 애플리케이션 내 두세 가지 구성 요소 간의 상호 작용을 검증합니다: 네트워크 계층과 리포지토리, 데이터베이스와 ViewModel 등입니다. E2E 테스트는 UI부터 외부 백엔드까지 전체 체인을 검증합니다. 통합 테스트가 API 요청이 올바른 JSON을 반환하는지 확인한다면, E2E 테스트는 사용자가 전체 로딩 주기 후에 이 데이터를 화면에서 볼 수 있는지 확인합니다.

유지보수 비용도 다릅니다. 통합 테스트는 제어된 환경(테스트 스텁, 인메모리 데이터베이스)에서 작동하여 안정적이고 빠릅니다. E2E 테스트는 외부 시스템 상태, 네트워크 가용성 및 백엔드 버전에 따라 달라져 거짓 양성(flakiness) 가능성이 높아집니다. Google Testing Blog(2021)에 따르면, E2E 테스트는 통합 테스트보다 평균 3~5배 더 취약하므로, 재시도 메커니즘과 안정성 분석 도입이 필요합니다.

E2E와 통합 테스트 중 선택은 시나리오의 중요성에 따라 달라집니다. 주요 사용자 경로(등록, 결제, 계정 복구)는 E2E 검증이 필요합니다. 보조 시나리오(목록 로딩, 프로필 업데이트)는 개별 화면 수준의 UI 검증이 포함된 통합 테스트로 충분히 다룰 수 있습니다.

E2E 테스트로 다루어야 할 시나리오

모든 사용자 시나리오가 E2E 테스트를 필요로 하는 것은 아닙니다. 선정 기준에는 세 가지 요소가 포함됩니다: 경로 사용 빈도, 프로덕션에서의 오류 비용, 관련된 시스템 수입니다. 모든 사용자가 첫 실행 시 수행하는 시나리오(온보딩, 등록)는 명백한 대상입니다. 사용자의 5%만 접근하는 관리자 패널 시나리오는 통합 테스트 대상입니다.

• 등록 및 로그인 — 이메일 확인 및 세션 설정을 포함한 전체 계정 생성 주기입니다. 오류 발생 시 모든 신규 사용자가 차단됩니다.
• 주문 및 결제 — 장바구니 확인, 배송 방법 선택, 타사 게이트웨이를 통한 결제 처리 및 확인 표시를 검증합니다.
• 비밀번호 복구 — 재설정 요청, 이메일 수신, 새 비밀번호 입력, 새 데이터로 로그인입니다. 서버 로직 변경 시 자주 깨집니다.
• 데이터 동기화 — 한 기기에서 레코드 생성 후 클라우드를 통한 동기화 후 다른 기기에서의 표시를 확인합니다.
• 푸시 알림 — 알림 수신, 알림을 통한 앱 화면 이동, 알림 후 상태 업데이트입니다.

각 시나리오에 대해 최소 E2E 테스트 세트가 결정됩니다 — 하나의 happy path와 하나의 error path(예: 만료된 토큰 또는 서버 다운)입니다. 기본 시나리오를 넘어선 E2E 커버리지 확장은 경제적으로 타당해야 합니다: E2E 테스트의 ROI는 10~15개의 주요 경로를 커버한 후 감소하며, 추가 E2E 테스트가 품질 확신에 비례적인 향상을 제공하지 않기 때문입니다.

E2E 테스트 도구

모바일 E2E 테스트에는 세 가지 주요 도구 범주가 있습니다: 플랫폼별 프레임워크, 크로스 플랫폼 솔루션 및 차세대 도구입니다. 도구 선택은 기술 스택, 팀 역량 및 CI 통합 설정 속도에 따라 달라집니다.

플랫폼별 프레임워크

XCUITest — Xcode에 포함된 Apple의 iOS 네이티브 도구입니다. iOS에서 가장 안정적이고 성능이 뛰어난 옵션으로, 시스템의 Accessibility 계층에 직접 접근합니다. Espresso — AndroidX Test에 포함된 Google의 Android 네이티브 프레임워크입니다. E2E 시나리오의 경우 Espresso는 AndroidX Test Orchestrator와 함께 사용되어 테스트를 격리하고 상호 영향을 방지합니다. 플랫폼별 프레임워크의 단점은 각 플랫폼마다 별도로 테스트를 작성해야 한다는 점입니다.

크로스 플랫폼 솔루션

Appium — WebDriver 기반 도구로, Java, Python, JavaScript 등 여러 언어를 지원합니다. Appium 아키텍처에는 명령을 플랫폼 API(Android용 UIAutomator 및 iOS용 XCUITest)로 프록시하는 서버가 포함됩니다. 각 기기에 대한 Desired Capabilities 설정이 필요합니다. Detox(Wix) — React Native용 프레임워크로, JS 스레드와 동기화되어 애니메이션 및 네트워크 요청 완료를 자동으로 기다립니다. Detox는 Jest 또는 Mocha와 통합되며 서버 설치가 필요 없습니다.

차세대 도구

Maestro — YAML 파일을 사용하여 시나리오를 설명하는 최신 프레임워크입니다. Maestro는 컴파일이 필요 없고, 핫 리로드를 지원하며, 결과 분석을 위한 내장 Flow Report를 제공합니다. 이 도구는 10분 안에 CI에 통합되며 애플리케이션 상태와 자동으로 동기화되어 Appium에 비해 테스트의 flakiness를 크게 줄입니다.

• Detox(Wix) — JS 스레드와 동기화되는 React Native 프레임워크입니다. Android 및 iOS를 지원하며 애니메이션 및 네트워크 요청 완료를 자동으로 기다립니다.
• Appium — WebDriver 기반 크로스 플랫폼 도구로, 모든 프로그래밍 언어를 지원합니다.
• Maestro — YAML 시나리오를 사용하는 최신 프레임워크로, 컴파일이 필요 없으며 10분 안에 CI에 통합됩니다.

E2E 테스트 코드 예제

가장 빠르게 성장하는 모바일 테스트 도구 중 하나인 Maestro의 로그인 시나리오 E2E 테스트를 살펴보겠습니다. Maestro는 YAML 형식을 사용하여 프로그래밍 언어 지식 없이도 테스트를 작성할 수 있습니다. 두 번째 예제는 React Native 앱을 위한 Detox E2E 테스트입니다.

Maestro: YAML 로그인 시나리오

시나리오는 전체 흐름을 설명합니다: 앱 실행, 이메일 및 비밀번호 입력, 로그인 버튼 클릭, 메인 화면 표시 확인입니다. Maestro 명령어는 직관적이며 선택자 설정이 필요 없습니다 — 프레임워크는 요소 텍스트를 사용하여 요소를 찾습니다.

# E2E: 사용자 로그인
appId: com.example.myapp
---
- launchApp
- waitForVisibile:
    text: "Email"
- tapOn:
    text: "Email"
- inputText:
    text: "user@example.com"
- tapOn:
    text: "Password"
- inputText:
    text: "secret123"
- tapOn:
    id: "loginButton"
- waitForVisibile:
    text: "Welcome back!"
- assertVisible:
    text: "Welcome back!"

Detox: React Native용 E2E 테스트

Detox(Wix)는 JS 스레드와의 자동 동기화 덕분에 테스트 안정성을 보장합니다. 테스트는 sleep을 사용하지 않습니다 — Detox는 확인 전에 모든 비동기 작업이 완료될 때까지 기다립니다.

describe('Login flow', () => {
    beforeEach(async () => {
        await device.reloadReactNative()
    })

    it('should login successfully', async () => {
        await expect(element(by.id('emailInput'))).toBeVisible()
        await element(by.id('emailInput')).typeText('user@example.com')
        await element(by.id('passwordInput')).typeText('secret123')
        await element(by.id('loginButton')).tap()
        await expect(element(by.text('환영합니다!'))).toBeVisible()
    })
})

CI/CD 파이프라인의 E2E 테스트

CI/CD에 E2E 테스트를 통합하는 것은 효과성의 핵심 요소입니다. 권장 전략은 2단계 파이프라인입니다: 각 pull request 시 최소 smoke 테스트 세트(3~5개의 중요 E2E 시나리오)가 실행되고, 전체 회귀 테스트 세트는 야간(nightly build) 또는 릴리스 전에 실행됩니다. 이 접근 방식은 피드백 속도와 검증 깊이의 균형을 유지합니다.

CI에서 E2E 테스트에는 세 가지 측면이 중요합니다: 병렬화 — Firebase Test Lab 또는 AWS Device Farm을 통해 여러 기기에서 동시에 테스트를 실행하여 실행 시간을 시간에서 분 단위로 단축합니다; 환경 컨테이너화 — 백엔드 및 테스트 서버에 Docker를 사용하여 재현성을 보장합니다; 보고 및 재시도 — 실패한 테스트 자동 재시작(최대 2회) 및 각 시나리오 실행 비디오가 포함된 HTML 보고서 생성입니다.

Google Testing Blog(2022)에 따르면, 병렬 실행이 포함된 전용 E2E CI 파이프라인을 사용하는 팀은 회귀 발견 시간을 60% 단축합니다. E2E 테스트 효과성의 핵심 지표는 테스트 수가 아니라 거짓 양성 없는 성공적인 CI 실행 비율입니다. 목표는 중요한 경로를 완전히 커버하면서 E2E 세트 안정성을 95% 이상으로 유지하는 것입니다.