• 테스트 자동화의 시작 - Cypress 기반 E2E 테스트 도입기
  • 들어가며
  • 테스트의 종류와 역할
    • 유닛 테스트 (Unit Test)
    • 통합 테스트 (Integration Test)
    • E2E(End-to-End) 테스트
  • E2E 테스트 도입 배경
    • 반복적인 수동 QA의 비효율성 인지
    • 유닛 테스트를 넘어
  • Cypress 도구 선택과 장점
  • Cypress 활용 사례
    • API Mocking
    • 사용자 정의 명령(Custom Commands) 사용
    • 비동기 처리
    • API Mocking과 비동기 처리의 혼합 사용
    • 테스트코드 작성을 좀 더 쉽게
      • testing-library 소개
      • 접근성 기반 요소 선택
      • 상호작용 시뮬레이션
      • BDD: Cucumber 소개
      • 그 외의 추가 전략
  • 테스트 목표 및 범위 설정
    • 단계 1: 성공적인 흐름(Happy Path) 검증
    • 단계 2: 디테일한 사용자 흐름 검증
    • 단계 3: 엣지 케이스와 예외 상황 검증
  • CI/CD와 테스트 자동화 연동
  • 마치며

들어가며

안녕하세요. 카카오모빌리티 웹FE개발팀에서 프론트엔드 개발을 맡고 있는 란입니다. 프론트엔드 개발에서 테스트 자동화는 점점 더 중요해지고 있습니다. 다양한 브라우저 환경, 사용자 입력, 복잡한 UI 등 여러 변수를 다뤄야 하며, 빠른 릴리스 주기에 대응해야 하기 때문입니다.

하지만 테스트 코드를 작성하고 유지 보수하는 일은 쉽지 않은 과제입니다. 새로운 기능 개발이나 디자인 변경이 잦은 환경에서는 테스트 코드가 레거시화되거나, 오히려 개발 속도를 저하하는 요인이 되기도 합니다. 이러한 문제를 해결하기 위해 E2E 테스트를 도입해 반복적이고 지루한 수동 QA의 부담을 덜고, 주요 사용자 흐름에서 안정성을 확보하는 경험을 했습니다.

이 글에서는 제가 경험한 E2E 테스트의 필요성, Cypress 도입 과정, 그리고 적용 사례를 공유하며 테스트 자동화를 고민하는 분들께 조금이나마 도움이 되고자 합니다.

테스트의 종류와 역할

소프트웨어 개발에서 테스트를 설계할 때는 효율성과 신뢰성을 모두 고려해야 합니다. 모든 테스트를 동등한 수준에서 작성할 수는 없기 때문에, 어떤 부분에 더 많은 리소스를 투자할지 우선순위를 정하는 것이 중요합니다. 이때 많이 활용되는 개념이 바로 테스트 피라미드입니다. 리소스 우선순위를 정하는 데 도움이 됩니다.

유닛 테스트 (Unit Test)

가장 작은 단위의 코드를 검증하는 데 초점이 맞춰져 있습니다. 자주 수정되는 코드에서도 안정성을 보장합니다. Jest나 React Testing Library와 같은 도구를 사용하여 독립적으로 검증합니다.

통합 테스트 (Integration Test)

여러 모듈 간의 상호작용을 검증합니다. 예를 들어 API 호출 후 데이터가 화면에 올바르게 렌더링 되는지를 확인합니다. 유닛 테스트만으로는 놓칠 수 있는 연계 문제를 발견할 수 있어, 시스템의 일관성을 보장할 수 있습니다. 통합 테스트는 유닛 테스트보다 작성하는 데 시간이 더 걸리지만 복잡한 시스템에서 중요한 부분을 검증하는 데 필요합니다.

E2E(End-to-End) 테스트

사용자의 관점에서 애플리케이션의 처음부터 끝까지 전체 흐름을 검증합니다. 로그인, 상품 결제, 페이지 이동 등 실제 사용자 행동을 시뮬레이션합니다. 주요 도구로는 Cypress, Playwright, Selenium 등이 있습니다.

E2E 테스트 도입 배경

반복적인 수동 QA의 비효율성 인지

담당하는 서비스의 배포 전 QA 과정에서는 항상 주요 사용자 흐름을 수동으로 검증해야 했습니다. 전체 페이지를 테스트하려면 100개 이상의 페이지 테스트 케이스를 확인해야 했습니다. 단조롭고 반복적인 작업이 큰 부담으로 작용했습니다. 또한 실수로 놓치는 부분이 생기거나 일관성이 부족한 점이 발견되기도 했습니다.

유닛 테스트를 넘어

초기에는 Jest를 사용해 유닛 테스트를 작성했습니다. 하지만 서비스 특성상 빈번한 기능 변경과 디자인 수정으로 인해 테스트 코드도 지속적으로 수정해야 했습니다. 특히, 유닛 테스트는 개별적인 컴포넌트나 로직의 안정성만 검증했기 때문에, 여러 모듈이 연계된 전체 사용자 흐름에서는 결함을 놓칠 위험이 있었습니다. 또한, 변화 속도에 맞춰 테스트 코드를 업데이트하기 어려워졌습니다. 결국 일부 테스트는 레거시화되어 유지보수에 부담이 되었습니다.

이러한 문제를 해결하기 위해 유닛 테스트나 통합 테스트 대신 E2E 테스트만을 선택해 운영하고 있습니다. 물론, 모든 테스트 방식을 도입할 수 있다면 이상적입니다. E2E 테스트만으로 모든 것을 해결할 수는 없다는 점도 잘 알고 있습니다. 하지만 빠르게 변화하는 환경에서, 작은 코드 단위의 안정성보다는 전체적인 사용자 흐름에서 안정성을 보장하는 것이 더 큰 가치를 제공한다고 판단했습니다.

Cypress 도구 선택과 장점

E2E 테스트 자동화 도구로는 Cypress, Playwright, Selenium을 주로 사용합니다. 각각 장단점이 있어서 프로젝트 상황에 맞춰 선택하는 것이 좋습니다. 이 세 테스트 자동화 도구들의 기능과 특징을 비교해보겠습니다.

표 1 Cypress, Selenium, Playwright 비교

기능/특징	Cypress	Playwright	Selenium
실시간 디버깅과 명령 로그	브라우저 화면에서 테스트 진행 상황을 실시간으로 확인 가능, 명령 로그로 애플리케이션 상태 추적	기본 디버깅 지원(개발자 도구 연동 가능)	로그 기반 디버깅 제공
자동 대기와 비동기 처리 지원	DOM(Document Object Model) 요소와 비동기 작업이 완료될 때까지 자동 대기, 타이밍 문제 최소화	DOM 요소 로드와 비동기 작업에 대한 스마트 대기 지원	수동으로 wait 명령 설정 필요
시각적 피드백	스크린샷과 동영상을 자동 기록, 실패 시점과 전체 실행 과정 저장 가능	스크린샷 및 동영상 기록 가능	스크린샷 기록 가능(별도 설정 필요)
간단한 설치와 사용 용이성	설치와 설정이 간단하여 빠르게 테스트 환경 구축 가능	비교적 간단(추가 설정이 필요할 수 있음)	설치와 설정이 복잡하며 초기 도입 비용이 높음
속도 및 성능	상대적으로 빠르지만, Playwright보다 약간 느림	매우 빠른 테스트 실행 속도 및 경량화	다양한 환경 지원으로 유연하지만, 속도가 느림

비교 결과 Cypress를 선택했습니다. Cypress는 실시간 디버깅, 자동 대기 기능, 시각적 피드백, 그리고 간단한 설치와 사용 용이성 측면에서 다른 도구들보다 우수하다고 판단했기 때문입니다.

Cypress 활용 사례

API Mocking

API Mocking은 네트워크 요청을 가로채어 클라이언트가 서버로부터 반환받는 데이터를 개발자가 지정한 값으로 대체하는 작업을 의미합니다. API Mocking을 통해 서버 상태와 관계없이 테스트를 독립적으로 수행할 수 있습니다. 실제 서버를 호출하지 않고도 다양한 시나리오(성공, 실패, 지연)를 검증할 수 있으며, 테스트 환경 구성을 간소화할 수 있습니다.

Cypress에서는 fixture를 통해 Mock 데이터를 효과적으로 관리할 수 있습니다. 개발자는 특정 API 호출에 대해 미리 정의된 응답 (예: searchResult.json)을 반환하도록 설정할 수 있어 안정적인 테스트 환경을 구축할 수도 있습니다.

결제 프로세스에서 Mock 데이터를 사용하여 결제가 성공하거나 실패하는 상황을 예로 들어 보겠습니다.

describe('API Mocking 예제 ‘, () => {
    beforeEach(() => {
        // 검색 결과 API Mocking
        cy.intercept('GET', '/api/search?query=example', {
            fixture: 'searchResults.json', // Mock 데이터 파일
        }).as('getSearchResults');
    });

    it('should display mocked search results', () => {
        // 검색 실행
        cy.get('#search-button').click();

        // API 호출 확인
        cy.wait('@getSearchResults').its('response.statusCode').should('eq', 200);

        // 데이터가 UI에 올바르게 표시되는지 확인
        cy.get('#search-result-item').should('have.length', 3); // 3개의 결과 값 확인
        cy.contains('상품 1').should('be.visible'); // 특정 데이터 항목 확인
    });
});
describe('API Mocking 예제 ‘, () => {
    beforeEach(() => {
        // 검색 결과 API Mocking
        cy.intercept('GET', '/api/search?query=example', {
            fixture: 'searchResults.json', // Mock 데이터 파일
        }).as('getSearchResults');
    });

    it('should display mocked search results', () => {
        // 검색 실행
        cy.get('#search-button').click();

        // API 호출 확인
        cy.wait('@getSearchResults').its('response.statusCode').should('eq', 200);

        // 데이터가 UI에 올바르게 표시되는지 확인
        cy.get('#search-result-item').should('have.length', 3); // 3개의 결과 값 확인
        cy.contains('상품 1').should('be.visible'); // 특정 데이터 항목 확인
    });
});

코드가 숨겨졌습니다.

사용자 정의 명령(Custom Commands) 사용

Cypress에서는 반복적으로 사용하는 테스트 코드를 Command로 묶을 수 있습니다. 이를 통해 테스트 코드의 가독성과 재사용성을 높일 수 있습니다. 상품을 조회 하는 과정에서 자주 반복되는 입력 및 버튼 클릭 동작을 Command로 정의하는 예시를 들어보겠습니다.

예시 코드 commands.js 파일에 사용자 정의 명령 추가

Cypress.Commands.add('applyFilter, (필터명, 필터값) => {
    cy.get(`[data-filter="${필터명}"]`).click(); // 필터 옵션 열기
    cy.get(`[data-option="${필터값}"]`).click(); // 필터 값 선택
    cy.get('#apply-filter-button').click(); // 필터 적용 버튼 클릭
});
Cypress.Commands.add('applyFilter, (필터명, 필터값) => {
    cy.get(`[data-filter="${필터명}"]`).click(); // 필터 옵션 열기
    cy.get(`[data-option="${필터값}"]`).click(); // 필터 값 선택
    cy.get('#apply-filter-button').click(); // 필터 적용 버튼 클릭
});

코드가 숨겨졌습니다.

테스트 파일에서 아래처럼 간단히 재사용할 수 있습니다.

describe('Custom Commands를 활용한 상품 필터링 테스트', () => {
    beforeEach(() => {
        cy.visit('/products'); // 상품 검색 페이지로 이동
    });

    it('특정 필터를 적용하여 상품 목록을 업데이트한다', () => {
        // Custom Command로 필터 적용
        cy.applyFilter('카테고리', ‘대한항공 항공권’; // '대한항공 항공권 ’ 카테고리 필터 적용
        cy.applyFilter('가격', '10만원 이하'); // '10만 원 이하' 가격 필터 적용

        // 필터 적용 결과 확인
        cy.get('#product-item').should('have.length', 3); // 필터 결과로 3개 항목 확인
        cy.contains('상품 1').should('be.visible'); // 필터 결과로 포함된 항목 확인
    });
});
describe('Custom Commands를 활용한 상품 필터링 테스트', () => {
    beforeEach(() => {
        cy.visit('/products'); // 상품 검색 페이지로 이동
    });

    it('특정 필터를 적용하여 상품 목록을 업데이트한다', () => {
        // Custom Command로 필터 적용
        cy.applyFilter('카테고리', ‘대한항공 항공권’; // '대한항공 항공권 ’ 카테고리 필터 적용
        cy.applyFilter('가격', '10만원 이하'); // '10만 원 이하' 가격 필터 적용

        // 필터 적용 결과 확인
        cy.get('#product-item').should('have.length', 3); // 필터 결과로 3개 항목 확인
        cy.contains('상품 1').should('be.visible'); // 필터 결과로 포함된 항목 확인
    });
});

코드가 숨겨졌습니다.

비동기 처리

Cypress는 요소가 DOM에 나타날 때까지 cy.get 및 cy.contains와 같은 명령어를 자동으로 대기합니다. 이를 통해 테스트 코드에서 수동으로 wait를 설정할 필요 없이 비동기적인 요소 로드 지연 문제를 쉽게 처리할 수 있습니다.

describe('상품 목록을 가져온다, () => {
    beforeEach(() => {
        cy.visit('/products'); // 상품 목록 페이지로 이동
    });

    it('페이지 로드 후 상품 목록이 올바르게 표시된다', () => {
        // 상품 목록이 로드되었는지 확인
        cy.get('#product-item', { timeout: 10000 }) // 최대 10초까지 대기
           .should('have.length.at.least', 1); // 최소 1개 이상의 상품이 로드되었는지 확인

        // 특정 상품 항목이 표시되었는지 확인
        cy.contains('상품 1').should('be.visible'); // 상품 이름 1이 화면에 나타나는지 확인
    });
});
describe('상품 목록을 가져온다, () => {
    beforeEach(() => {
        cy.visit('/products'); // 상품 목록 페이지로 이동
    });

    it('페이지 로드 후 상품 목록이 올바르게 표시된다', () => {
        // 상품 목록이 로드되었는지 확인
        cy.get('#product-item', { timeout: 10000 }) // 최대 10초까지 대기
           .should('have.length.at.least', 1); // 최소 1개 이상의 상품이 로드되었는지 확인

        // 특정 상품 항목이 표시되었는지 확인
        cy.contains('상품 1').should('be.visible'); // 상품 이름 1이 화면에 나타나는지 확인
    });
});

코드가 숨겨졌습니다.

API Mocking과 비동기 처리의 혼합 사용

API Mockcing과 비동기 처리는 상황에 맞춰서 혼합해서 사용하고 있습니다.

표 2 API Mocking과 비동기 처리 테스트 비교표

기준	API Mocking	비동기 처리 테스트
테스트 목적	클라이언트 로직 검증에 집중	클라이언트와 서버 간 통합 검증
데이터 제어	고정된 데이터, 다양한 시나리오 제어 가능	실제 서버에서 제공하는 데이터를 사용
네트워크 상태	네트워크 의존성 없음	네트워트 안정성 필요
속도	빠름	상대적으로 느림
사용 사례	개발 초기, 서버 미완성, 오류/지연 상황 재현	실제 환경에서 클라이언트-서버 통합 테스트

아래와 같이 예시를 들어볼 수 있습니다.

• 결제: API Mocking을 사용하여 실제 결제를 처리하지 않도록 설정합니다. Mocking을 통해 성공, 실패, 지연과 같은 다양한 응답을 시뮬레이션하여 다양한 시나리오 테스트가 가능합니다.
• 상품 조회: 비동기 처리를 활용하여 클라이언트와 서버 간의 상호작용을 테스트합니다. 실제 서버 데이터를 기반으로 테스트하면 클라이언트-서버 동작을 검증할 수 있습니다.

테스트코드 작성을 좀 더 쉽게

testing-library 소개

​​@testing-library는 사용자 관점에서 테스트를 작성하도록 돕는 다양한 기능을 제공합니다. 유지보수성과 가독성이 높은 테스트 코드를 작성할 수 있는 것이 특징입니다.

접근성 기반 요소 선택

테스트를 위해 요소를 선택할 때 data-attribute를 사용하는 방식에는 몇 가지 아쉬운 부분이 있습니다. 테스트용 속성을 비즈니스 코드에 추가하면서 UI 코드와 테스트 코드 간의 결합도가 생깁니다. 이는 테스트가 애플리케이션의 순수한 구조와 동작에 영향을 미쳐 불필요한 의존성이 생기며, 유지보수성과 코드의 일관성을 떨어뜨릴 수 있습니다.

@testing-library를 활용하면 테스트 데이터 속성(data-testid)에 의존하지 않고 접근성 속성(예: aria-label, role)이나 화면의 텍스트를 기반으로 테스트를 작성할 수 있습니다. UI 변경에 덜 민감하고, 실제 사용자 경험과 더 유사하게 작성할 수 있도록 도와줍니다.

적용 전 data-testid에 의존하여 요소를 찾는 Cypress 코드로, 테스트 코드와 UI 코드 간의 결합도가 높았습니다.

describe('결제 프로세스 테스트 (적용 전)', () => {
    it('결제 버튼이 정상적으로 동작한다.', () => {
        // 결제 버튼을 data-testid로 선택
        cy.get('#payment-button’').click();

        // 성공 메시지를 data-testid로 확인
        cy.get('#success-message").should('be.visible');
    });
});
describe('결제 프로세스 테스트 (적용 전)', () => {
    it('결제 버튼이 정상적으로 동작한다.', () => {
        // 결제 버튼을 data-testid로 선택
        cy.get('#payment-button’').click();

        // 성공 메시지를 data-testid로 확인
        cy.get('#success-message").should('be.visible');
    });
});

코드가 숨겨졌습니다.

<button data-test-payment-button>결제하기</button>
...
<alert data-test-success-message>결제가 완료되었습니다</alert>
<button data-test-payment-button>결제하기</button>
...
<alert data-test-success-message>결제가 완료되었습니다</alert>

코드가 숨겨졌습니다.

적용 후 접근성 속성과 화면 텍스트를 기반으로 작성한 코드로 전환했습니다. 테스트 코드의 유지보수성이 향상되고 사용자 관점에서의 검증이 가능해졌습니다.

describe('결제 프로세스 테스트 (적용 후)', () => {
    it('결제 버튼이 정상적으로 동작한다', () => {
        // 버튼 역할과 텍스트로 결제 버튼 선택
        cy.findByRole('button', { name: /결제하기/i }).click();

        // 성공 메시지를 텍스트로 확인
        cy.findByText('결제가 완료되었습니다').should('be.visible');
    });
});
describe('결제 프로세스 테스트 (적용 후)', () => {
    it('결제 버튼이 정상적으로 동작한다', () => {
        // 버튼 역할과 텍스트로 결제 버튼 선택
        cy.findByRole('button', { name: /결제하기/i }).click();

        // 성공 메시지를 텍스트로 확인
        cy.findByText('결제가 완료되었습니다').should('be.visible');
    });
});

코드가 숨겨졌습니다.

상호작용 시뮬레이션

사용자가 실제로 수행하는 동작(클릭, 입력, 포커스 이동 등)을 시뮬레이션할 수 있도록 다양한 유틸리티를 제공합니다.

예시 userEvent.type과 userEvent.click을 사용해 사용자의 실제 상호작용을 시뮬레이션합니다.

요소 선택은 getByPlaceholderText와 getByRole을 사용해, 실제 UI의 접근성 속성이나 화면에 표시된 텍스트를 기반으로 이루어집니다. 사용자 경험과 더 유사하게 테스트 코드를 작성할 수 있고, 사용자 흐름을 직관적으로 표현합니다.

describe('상품 조회 테스트', () => {
    it('사용자가 상품을 검색하고 특정 상품을 클릭한다', () => {
        // 검색창에 키워드 입력
        userEvent.type(screen.getByPlaceholderText(/검색어를 입력하세요/i), '스마트폰');

        // 검색 버튼 클릭
        userEvent.click(screen.getByRole('button', { name: /검색/i }));

        // 특정 상품 클릭
        userEvent.click(screen.getByText(/제주 항공권/i));

        // 상품 상세 페이지 확인
        expect(screen.getByRole('heading', { name: /상품 상세 정보/i })).toBeInTheDocument();
    });
});
describe('상품 조회 테스트', () => {
    it('사용자가 상품을 검색하고 특정 상품을 클릭한다', () => {
        // 검색창에 키워드 입력
        userEvent.type(screen.getByPlaceholderText(/검색어를 입력하세요/i), '스마트폰');

        // 검색 버튼 클릭
        userEvent.click(screen.getByRole('button', { name: /검색/i }));

        // 특정 상품 클릭
        userEvent.click(screen.getByText(/제주 항공권/i));

        // 상품 상세 페이지 확인
        expect(screen.getByRole('heading', { name: /상품 상세 정보/i })).toBeInTheDocument();
    });
});

코드가 숨겨졌습니다.

BDD: Cucumber 소개

전체적으로 적용해보지는 못했지만 BDD(Behavior-Driven Development) 방식 도입을 고려해보기도 했습니다. BDD는 비기술적인 팀원도 이해할 수 있는 자연어 기반의 테스트 시나리오를 통해 협업과 가독성을 높이는 데 초점을 맞춥니다. 특히 여러 직군간의 커뮤니케이션을 원활히 하고 테스트 요구사항을 명확히 정의하는 데 유용할 수 있습니다.

TDD(Test-Driven Development)가 코드 단위와 로직 검증에 초점을 맞춘 개발자 중심의 접근 방식이라면, BDD는 시스템의 동작과 사용자 경험을 중심으로 요구사항을 표현해 실제 비즈니스 요구에 더 가깝게 테스트를 작성할 수 있는 장점이 있습니다.

예시

Feature: 항공권 상품 검색
    Scenario: 출발지와 도착지를 입력하여 검색 결과를 확인한다
        Given 사용자가 "항공권 검색 페이지"에 접속했을 때
        When 출발지 입력란에 "서울"을 입력하면
        Then "서울 김포공항"과 같은 자동완성 리스트가 표시된다
        When 도착지 입력란에 "도쿄"를 입력하면
        Then "도쿄 나리타공항"과 같은 자동완성 리스트가 표시된다
        And 사용자가 "검색" 버튼을 클릭하면
        Then 검색 결과에 항공권 목록이 표시된다

    Scenario: 출발지나 도착지를 입력하지 않은 경우 에러 메시지를 표시한다
        Given 사용자가 "항공권 검색 페이지"에 접속했을 때
        When 출발지나 도착지 중 하나를 입력하지 않고 "검색" 버튼을 클릭하면
        Then "출발지와 도착지를 모두 입력해주세요"라는 에러 메시지가 표시된다
Feature: 항공권 상품 검색
    Scenario: 출발지와 도착지를 입력하여 검색 결과를 확인한다
        Given 사용자가 "항공권 검색 페이지"에 접속했을 때
        When 출발지 입력란에 "서울"을 입력하면
        Then "서울 김포공항"과 같은 자동완성 리스트가 표시된다
        When 도착지 입력란에 "도쿄"를 입력하면
        Then "도쿄 나리타공항"과 같은 자동완성 리스트가 표시된다
        And 사용자가 "검색" 버튼을 클릭하면
        Then 검색 결과에 항공권 목록이 표시된다

    Scenario: 출발지나 도착지를 입력하지 않은 경우 에러 메시지를 표시한다
        Given 사용자가 "항공권 검색 페이지"에 접속했을 때
        When 출발지나 도착지 중 하나를 입력하지 않고 "검색" 버튼을 클릭하면
        Then "출발지와 도착지를 모두 입력해주세요"라는 에러 메시지가 표시된다

코드가 숨겨졌습니다.

그 외의 추가 전략

입력 데이터를 난수화하거나, UI 변경 사항으로 인해 발생할 수 있는 의도하지 않은 화면 렌더링을 탐지하기 위해 Visual Regression Testing도 고려해볼 수 있습니다.

테스트 목표 및 범위 설정

테스트 코드를 작성하다 보면 어디까지 테스트를 해야 할지 막막할 때가 많았습니다. 초기 단계에서는 세세한 부분에 얽매이지 않고 비교적 큰 범위에서 시작하는 전략을 선택했습니다. 이후 테스트를 점진적으로 보완하며 더 구체적이고 세분화된 검증을 추가해나갔습니다.

단계 1: 성공적인 흐름(Happy Path) 검증

초기 단계에서는 애플리케이션의 주요 기능이 올바르게 작동하는지 확인하는 데 초점을 맞췄습니다. 사용자들이 가장 많이 사용하는 주요 흐름인 상품 검색, 조회, 결제, 취소를 중심으로 Happy Path를 검증했습니다. 이 단계에서는 성공적인 시나리오에만 집중하며, 간단한 데이터와 성공적인 입력값을 사용해 테스트를 구성했습니다. 주요 사용 시나리오가 안정적으로 동작함을 보장하면서, 테스트 작성에 걸리는 시간을 단축시킬 수 있었습니다.

단계 2: 디테일한 사용자 흐름 검증

실제 사용자 관점에서의 디테일한 흐름을 검증했습니다. 단순히 기능의 성공 여부만 확인하는 것이 아니라, UI와 기능이 직관적으로 동작하는지를 확인하는 데 중점을 두었습니다. 사용자 경험을 고려하여 화면 전환과 UI 상태(버튼 활성화 여부, 오류 메시지 표시 등)를 검증했습니다. 잘못된 정보를 입력했을 때 에러 메시지가 표시되는지, 결제 실패 등 의도한 테스트 케이스들이 자연스럽게 동작하는지 테스트했습니다.

단계 3: 엣지 케이스와 예외 상황 검증

실패나 에러 케이스일때도 안정적으로 동작하는지를 확인했습니다. API 호출이 실패했을 때 적절한 오류 메시지가 표시되고 정상적으로 노출 되는지 등의 케이스를 추가했습니다.

초기에는 빠르게 테스트를 작성하고 핵심 흐름을 검증하는 데 집중할 수 있게 했고, 이후에는 사용자 경험을 반영한 세부 검증과 예외 처리를 추가하며 서비스 품질을 지속적으로 보완해나갔습니다.

CI/CD와 테스트 자동화 연동

E2E 테스트는 배포 파이프라인(CI/CD)과 연동하여 더 효과적으로 활용할 수 있습니다. 예를 들어, Pull Request(PR)가 생성되면 자동으로 E2E 테스트가 실행되고, 테스트가 실패할 경우 즉시 알림을 받아 빠르게 문제를 파악하고 수정할 수 있습니다. 이 방식은 주요 시나리오에 문제가 발생했을 때 배포 전에 빠르게 발견하고 수정할 수 있어 릴리스의 안정성을 높이는 데 도움이 됩니다. GitHub Actions와 같은 CI 도구를 사용하여 PR 생성 시 Cypress 테스트를 자동으로 실행하고, 그 결과를 메신저 등으로 통지할 수 있습니다. 이러한 연동 방식은 테스트 자동화의 효과를 극대화하고, 코드 품질 관리와 배포 주기를 더 효율적으로 만들 수 있는 유용한 방법입니다.

마치며

E2E 테스트 자동화를 도입하면서 "이 정도면 충분할까?"라는 고민은 계속 됐습니다. 코드가 변경될 때 마다 테스트도 유지보수를 해야하는 점이 때로는 부담으로 다가왔고, 제한된 자원 속에서 어떤 부분까지 신경 써야 할지 혼란스러울 때도 있었습니다. 그래도 이런 과정을 통해 개발자들에게는 코드 변경으로 인한 배포의 두려움을 줄이고, 사용자들에게는 안정적이고 신뢰할 수 있는 경험을 제공할 수 있다는 점에서 보람을 느꼈습니다.

E2E 테스트를 도입한 결과, 주요 사용자 흐름을 자동화하여 반복적인 수동 테스트의 부담을 줄일 수 있었습니다. 덕분에 기능 배포 시 모든 주요 시나리오를 직접 검증하지 않아도 되었고, 빠른 피드백과 릴리스 주기를 유지할 수 있었습니다.

테스트 자동화는 개발 속도 향상뿐 아니라 다양한 변수 속에서도 서비스가 안정적으로 동작하도록 기반을 다지는 작업입니다. 사용자들은 각기 다른 네트워크 상황, 입력값, 디바이스 환경에서 서비스를 이용합니다. 이런 다양한 조건에서도 안정적인 동작을 보장하는 것이 목표입니다.

앞으로도 더욱 다양한 케이스를 고려하고, 테스트를 지속적으로 개선해 나갈 것입니다. 이를 통해 개발자들에게는 생산성과 안정성을, 사용자들에게는 만족스러운 경험을 제공하는 서비스를 만들고자 합니다. 이러한 노력이 모두에게 긍정적인 영향을 미칠 수 있기를 기대합니다.