프론트엔드 E2E 테스팅 (with Cypress)

 

💡 이번 포스트는 사내 위클리에서 발표한 내용을 정리한 것입니다.

 

📌 들어가며

 

작년 12월부터 약 3개월간 항공 웹 개발을 진행했는데, 생각보다 다양한 동선이 있어서 고생을 했던 기억이 있습니다.

더군다나 제가 진행했던 업무(웹 허브 오픈, TF v12 전환)가 항공의 전체적인 동선에 적용이 필요했던 것들이어서 더욱 그랬던 것 같은데요.

아직 E2E 테스트 작성경험이 없어서 이번 기회에 공부도 해볼 겸 국제선 예약동선의 E2E 테스트를 진행해봤습니다.

 

📌 E2E 테스트란?

우선 간단하게 E2E 테스트가 무엇인지 살펴보겠습니다.

흔히 E2E (End to End) 테스트는 브라우저 환경에서 유저가 사용하고 있다는 가정하에

애플리케이션의 전체적인 동작을 검증하는 것을 말합니다.

 

유닛 테스트와 통합 테스트에서는 각 모듈의 무결성을 검증할 수 있다면,

E2E 에서는 이러한 모듈들이 잘 섞여서 필요한 기능을 문제없이 제공하는지 검증할 수 있습니다.

 

출처 : https://www.headspin.io/blog/the-testing-pyramid-simplified-for-one-and-all

 

대신 그만큼 다양한 시나리오를 검증하기 때문에 다른 방법들에 비해 테스트 비용이 비싼 것도 사실입니다.

하지만 항공웹과 같이 다양한 동선을 검증해야하는 경우 E2E 테스트를 통한 기능적 회귀로

새로운 기능 개발 혹은 버그 수정시에 안정감을 가져다 줄 수 있을 것입니다.

 

📌 항공웹 동선 정리

테스트를 작성하기 전에 먼저 현재 항공웹 동선을 파악해봅시다.

우선 가장 기본이 되는 예약동선을 크게 나누면 다음과 같습니다.

 

국내선

• 웹, 앱, 메타(b2c - skyscanner, naver)

국제선

• 웹, 앱, 메타(b2c - skyscanner)

그리고 각각의 동선은 다음 흐름으로 이어집니다.

 

허브 → 항공편 검색 목록 → 항공편 상세 → 예약하기 → 결제하기 → 발권완료 → (내 예약상세 || 허브)

 

이외에도 세부적으로 여행자 보험, PLCC 등등 다양한 동선이 있습니다.

이러한 동선들은 국내선/국제선 등에 공통으로 녹아져 있는 경우가 있습니다.

 

좀 더 직관적인 테스트 코드 관리를 위해 이러한 동선들은

메인 동선과 동일한 위계로 보고 테스트 코드를 추가하는 방향으로 진행해봤습니다.

 

integration
 ㄴ intl
 ㄴ domestic
 ㄴ b2c
        ㄴ naver
        ㄴ skyscanner
 ㄴ plcc
 ㄴ ... 그외 cross-sub-domain 기능들

 

국내선은 이전에 eeyore이 작업해주신 것이 있어서 이번에는 국제선 예약 동선의 e2e 테스트를 구성해보기로 했습니다.

 

📌 Cypress 의 특징 살펴보기

Cypress 의 몇가지 대표적인 특징에 대해서 알아봅시다.

1️⃣ functional test runner

Cypress 는 functional test runner 입니다.

앱이 사용자 관점에서 의도한대로 동작하는지 검증하는데 사용됩니다.

 

2️⃣ 비동기적인 element 탐색방식

상황에 따라 element 가 바로 로드되지 못하는 경우가 있는데,

cypress 에서는 element query 를 비동기적으로 하기에 내부적으로 timeout 이 되기 전까지 재요청을 시도합니다.

 

3️⃣ retryability

모던 웹앱은 비동기 동작이 많은데, cypress 의 retryability 덕분에 별도의 동기처리없이 직관적인 테스트 코드 작성이 가능합니다.

기본적으로 엘리먼트를 찾는 query 를 포함하여 특정 동작을 수행하는 action (ex. click) 들도

일정 timeout 까지 요청을 재반복하기 때문에 이런 처리에 일일히 신경쓰지 않고 테스트 코드 작성에 집중할 수 있습니다.

(물론 그렇기에 잘못 사용하면 디버깅에 애를 먹을수도 있습니다.)

 

4️⃣ Promise 기반의 체이닝 방식으로 동작

읽기 쉬운 테스트 코드 작성이 가능하지만 동기적인 로직을 작성할 때 주의가 필요합니다.

 

5️⃣ record & screenshot

cypress 에서는 테스트 이후 결과물을 video, screenshot 형태로 저장할 수 있는 기능을 제공해줍니다.

이러한 결과물은 headless 환경에서 테스트 실패 원인을 찾는데 도움이 되며

현재 항공웹에서는 github actions 의 artifacts 를 통해서 테스트 결과물을 관리하고 있습니다.

 

📌 테스트 코드 어떻게 작성할까

1️⃣ 기획서 기반의 시나리오 작성

E2E 테스트를 통해 반복되는 주요 동선을 검증할 수 있고,

이는 곧 해당 프로젝트를 설명하는 하나의 문서 와 같은 역할을 한다고 생각합니다.

그렇기에 해당 서비스의 기획서를 바탕으로 플로우를 정리하는게 가장 정확하고 유의미할 것이라 생각되었습니다.

 

📝 항공 국제선 플로우 정리

제가 약 3개월간 항공쪽 개발을 하며 파악했던 주요 동선들을 위주로 플로우를 러프하게 정리해봤습니다.

세부적으로 정말 다양항 동선이 있지만, 여기서는 핵심만 정리하여 나타냈습니다.

1. 허브
국제선 검색 조건을 입력하고 "항공권 검색" 을 클릭하면 국제선 [항공편 검색 페이지] 로 이동한다.

2. 항공편 검색
- 필터를 통한 재검색이 되어야한다.
- 항공편 선택 시 <카드 프로모션 액션시트> 가 노출한다.
  ㄴ 선택한 프로모션으로 [항공편 상세페이지] 로 이동한다.

3. 항공편 상세
- "상세요금" 선택 시 <요금 상세 정보 팝업> 이 노출된다.
- "항공편 변경" 선택 시 이전 [항공편 검색목록 페이지] 로 이동한다.
- 인원변경 버튼 클릭 시 <인원 선택 팝업> 이 노출된다.
   ㄴ 새로운 인원타입이 추가될 경우 해당 조건으로 [항공편 검색 페이지] 로 이동하여 재검색한다.
   ㄴ 단순 인원추가 및 제거일 경우 가격 정보만 업데이트된다.
- "운임 및 수하물 규정 자세히보기" 선택 시 <항공사 운임 및 수하물 규정 팝업> 이 노출된다.
- "예약하기" 선택 시 [항공편 예약페이지] 로 이동한다.

4. 항공편 예약
- 예약자 정보와 탑승객 정보를 입력한 뒤에 약관에 전체동의하면 예약이 가능해진다.
- "예약하기" 선택 시 <예약정보 최종확인 팝업> 이 노출된다.
   ㄴ"네. 진행합니다." 선택 시 [항공편 결제페이지] 로 이동한다.

5. 항공편 결제
- 여정정보 및 탑승객정보 선택 시 <여정정보, 탑승객 정보 팝업>이 노출된다.
- 결제조건 변경 시 <결제 조건 변경 액션시트> 가 노출된다.
   ㄴ 결제 조건 선택 후 "선택한 조건으로 변경하기" 선택 시 선택된 조건으로 금액이 재조회된다.
- 카드번호, 유효기간, 비밀번호 앞 두자리, 카드 소유주 생년월일, 할부 개월 수를 입력하고 결제규정에 동의하면 결제가 가능해진다.
- "결제하기" 선택 시 결제가 이루어진다.

6. 발권완료
- "내 예약에서 확인" 선택 시 [국제선 내 예약상세 페이지]로 이동한다.

 

 

2️⃣ 테스트 형식 & 격리

일반적인 테스트는 다음 3가지 단계로 구성됩니다.

given
애플리케이션 특정 상태(state)에서

when 
특정 동작(action)을 수행할 때

then
의도대로 동작하는지 검증(assert)한다.

 

Cypress 를 통한 E2E 테스트를 수행할 때에는 여기서 좀 더 구체적인 단계의 정의가 필요할 것 같습니다.

 

visit
테스트할 특정 페이지에 방문해서

query & interaction
특정 컴포넌트를 찾아 상호작용을 통해

assertion
의도한대로 동작하는지 검증한다.

 

위 3단계로 수행되는 각각의 독립된 테스트 케이스를 추가합니다.

cypress 는 기본적으로 각각의 테스트 사이에 test state 를 모두 초기화합니다.

이를 통해 일관된 테스트 결과를 받을 수 있도록 합니다.

 

3️⃣ mocks-server 를 활용한 API 모킹

항공은 단순 조회 API 의 경우에도 캐시키 만료 등의 다양한 케이스로 인한 동선이 존재합니다.

조건에 따라 다른 테스트 결과를 얻게되면 테스트에 대한 신뢰도가 낮아지게 됩니다.

그렇기에 우리는 철저히 통제된 데이터가 필요한데, mocks-server 가 그 역할을 도와줍니다.

 

 

mocks-server 컨셉

 

 

mocks-server 를 통해 성공 및 실패 케이스 테스트에 필요한 API 들을 모킹해서 사용합니다.

항공웹은 현재 서버 API endpoint 를 환경변수로 관리하고 있어 간편하게 위임이 가능합니다.

다음은 국제선 항공권 검색 API 를 모킹한 예시입니다.

 

// mocks/routes/intl-search.js

const SEL_NYC_RESULTS_FIXTURE = [/** 서울 <-> 뉴욕 검색결과 모킹데이터 */]

module.exports = [
    {
    id: 'search-intl-flights',
    url: '/api/air/intl/search/flights/:key',
    method: 'POST',
    variants: [
      {
        id: 'success',
        response: (req, res) => {
          const sortCriteria = req.body['sort'] ?? 'PRICE'
          const airlineCriteria = req.body['filter']['byAirline']

          let contents = SEL_NYC_RESULTS_FIXTURE.contents

          if (airlineCriteria) {
            contents = SEL_NYC_RESULTS_FIXTURE.contents.filter((content) =>
              content.schedules.some((schedule) =>
                airlineCriteria.includes(schedule.carrier.code),
              ),
            )
          }

          /** 가격, 가는날 출발시간 순 정렬만 모킹 */
          if (sortCriteria === 'OUTBOUND_DEPARTURE_TIME') {
            contents.sort((a, b) =>
              moment(a.schedules[0].departureDateTime).isBefore(
                b.schedules[0].departureDateTime,
              )
                ? -1
                : 1,
            )
          } else {
            contents.sort((a, b) => a.totalPrice - b.totalPrice)
          }

          res.send({
            ...SEL_NYC_RESULTS_FIXTURE,
            contents,
            page: {
              currentPage: 1,
              pageSize: 20,
              totalCount: contents.length,
            },
            status: contents.length > 0 ? 'COMPLETE' : 'NO_DATA',
          })
        },
      },
    ],
  }
]

 

📌 Cypress 사용 시 유용한 팁과 기능들

1️⃣ default selector 우선순위

data-cy
data-test
data-testid
data-qa
id
class
tag
attributes
nth-child

 

테스트를 할때 상호작용할 엘리먼트를 찾을 때 사용하는 selector 는 위와 같은 우선순위를 가집니다.

dom 이나 css 속성에 의존할 경우 UI 변경에 따른 테스트 코드 관리 측면에서 취약하기 때문에

data- 를 사용하는 커스텀 테스트 id 를 부여하는 방식이 권장됩니다.

이번 국제선 E2E 테스트 코드에서도 우선적으로 data-cy 를 통한 유일한 test id 를 부여하는 방식으로 진행했습니다.

 

다만 직접적인 제어가 불가능한 외부 패키지 UI 컴포넌트의 요소를 검색해야하는 경우에는

태그 타입, class 명 등의 속성 선택자들을 조합해서 사용했습니다.

 

예시- background image 로만 처리되어있는 nav-item

 

주의할 점은, styled-component 등을 이용해서 생성한 내부 컴포넌트의 경우에는

className 이 production build 시에 최적화 과정에서 변경되기 때문에 사용하지 않는 것이 좋습니다.

 

element select 의 best practice 는 공식문서에 나와있습니다.

Best Practices | Cypress Documentation

Best Practices | Cypress Documentation

 

2️⃣ 자주 참조되는 엘리먼트는 alias 지정하기

동일한 문맥에서 자주 참조되는 element 는 alias 지정을 통해 query 문을 작성할 수 있습니다.

cy.get('.DayPicker-Day--today').as('today')

cy.get('@today').next().click()
cy.get('@today').next().next().click()

 

3️⃣ native clock override

시간과 관련된 동작을 제어해야하는 경우가 있습니다.

항공 메인(허브)에서 왕복 항공편을 선택할 때 출국일과 입국일을 달력에서 선택해야하는데,

이때 테스트의 간편함을 위해 오늘날짜로 현재 timestamp를 부여했습니다.

(국제선은 오늘 + 1 일부터 출국일을 선택해야하는 조건이 있음)

cy.clock(new Date(2023, 2, 13), ['Date'])

/** 허브에 진입 */
cy.visit('/')

이렇게하면 달력 컴포넌트에서 내부적으로 Date 함수가 호출되는 시점이 2023-02-13 이 되어 오늘 날짜를 원하는 날짜로 제어할 수 있습니다.

 

4️⃣ 매 테스트마다 수행되어야 하는 훅은 분리하기

각각의 테스트는 독립되도록 작성하되, 매 테스트 마다 동일한 과정을 반복해야한다면 이를 별도의 훅으로 분리할 수 있습니다.

cypress 에서는 Mocha 의 BDD 방식과 동일하게 훅을 정의할 수 있으며 여러 훅을 이용해 테스트마다 수행될 훅을 정의할 수 있습니다.

// 페이지 방문 예시 (beforeEach)
describe('국제선 항공편 결제 및 발권완료', () => {
  beforeEach(() => {
    cy.visit(
      '/payment?orderId=3950&id=AMADEUS_AC62G3AC726G3AC8997G3AC61G4&adult=1&child=0&infant=0&from=hub&requestTotalPrice=1067700&originDestination=c%3ASEL-c%3ANYC&inboundDate=2023-03-22&outboundDate=2023-03-15&cabinTypes=ECONOMY&cabinTypes=PREMIUM_ECONOMY&cabinTypes=BUSINESS&cabinTypes=FIRST&detailKey=087d07ff-9c99-4fc5-a166-d65bfcca769d%3A%3AAMADEUS_84e4d118-db54-4447-8aa8-e889af90e798%3A%3A1_1_2&cashRewardDefinitionId=f6938058-e534-4127-89e8-bbf73131635a',
    )
    cy.contains('결제내용 확인', { timeout: 60000 }).should('be.visible')
  })

    it('결제조건 변경 시 선택한 조건으로 결제정보가 재조회된다', () => {
        // ...
    })

    it('카드정보를 입력하고 결제가 완료되면 발권완료 페이지로 이동한다.', () => {
        // ...
  })
})

// 팝업 노출 예시 (afterEach)
describe('결제정보 관련 팝업을 노출한다.', () => {
  it('여정정보 팝업을 노출한다.', () => {
    // ...
  })

  it('탑승객정보 팝업을 노출한다.', () => {
    // ...
  })

  afterEach(() => {
    /** 팝업 닫기 */
    cy.get('.-triple-fallback-action').click()
  })
})

 

5️⃣ custom command 추가하기

cypress 는 custom command 를 통해 자주 사용하는 로직을 분리해서 인터페이스로 만들 수 있는 기능을 제공합니다.

여기서는 새로운 command 를 추가하거나, 기존의 command 를 overwrite 할 수 있습니다.

먼저 custom command 를 허용할 수 있도록 supportFile 옵션을 추가해줍니다.

 

// cypress.config.js

const { defineConfig } = require('cypress')

module.exports = defineConfig({
  e2e: {
    supportFile: 'cypress/support/index.ts',
        // ...
  },
  // ...
})

 

이제 트리플 로그인 시 설정되는 쿠키값을 세팅해주는 간단한 command 를 추가해보겠습니다.

command.ts 파일을 생성해서 index 에서 import 를 해오면,

별도의 import 문 없이 매 테스트 수행시마다 자동으로 불러와서 해당 command 들을 사용할 수 있습니다.

 

// cypress/support/index.ts

import './command'

// cypress/support/command.ts

Cypress.Commands.add('setupTripleUserCookie', () => {
  cy.setCookie('x-sample', 'test')
  cy.setCookie('x-session', 'test')
})

 

해당 command 에 대한 간단한 설명도 있으면 좋을 것 같네요.

이를 위해 Cypress 타입을 확장합니다.

 

// cypress/types/types.d.ts

declare namespace Cypress {
  interface Chainable {
    /**
     * 트리플 로그인 시 설정되는 쿠키값을 모킹합니다.
     * @example cy.setupTripleUserCookie()
     */
    setupTripleUserCookie(): void
  }
}

 

6️⃣ intercept 로 API spying

cypress 에서 제공하는 network intercept 도 유용한 기능입니다.

항공 국제선에서는 결제 페이지에서 선택한 카드 프로모션 정보가 바뀌면

해당 프로모션 id 로 결제정보를 재조회해야합니다.

 

서로다른 카드 프로모션 mocking 데이터를 만드는 것에는 한계가 있기 때문에

데이터를 확인하는 대신 재조회 API 를 다시 호출하는지 확인하는 것으로 테스트를 작성했습니다.

 

it('결제조건 변경 시 선택한 조건으로 결제정보가 재조회된다.', () => {
    /** 결제조건 변경을 위한 액션시트 선택 */
  cy.contains('결제 조건 변경').click()
  cy.get('div[class^="action-sheet-body"]')
    .contains('결제 조건 변경')
    .should('be.visible')
  cy.get('tr[class^=card-promotion-radios]').eq(0).click()

  cy.intercept({
    url: '/api/air/intl/booking/ticketing/ready/orders/*',
    method: 'GET',
    query: {
      cardPromotionPrincipleId: '*',
    },
  }).as('cardPromotionAppliedTicketingRequest')

  /** 카드 프로모션이 적용된 API 를 호출하는지 확인 */
  cy.get('button').contains('선택한 조건으로 변경하기').click()
  cy.wait('@cardPromotionAppliedTicketingRequest')
})

 

📌 Cypress test id 제거하고 배포하기

 

테스팅할때 test-id 를 부여하면 운영환경에서도 이 id 들이 유저들에게 그대로 노출되는 문제가 있습니다.

따라서 빌드 단계에서 이를 제거해줘야하는데, Next 12 부터 babel 대신 SWC 를 사용하면서

별도의 플러그인(babel-plugin-react-remove-properties) 없이 config 설정만으로 가능해졌습니다.

 

환경변수와 정규식을 이용해서 앞서 살펴본 cypress 용 test id 들을 production 빌드시에 걸러내줍니다.

 

// next.config.js

module.exports = {
compiler: {
    reactRemoveProperties:
      NODE_ENV === 'production'
        ? {
            properties: ['^data-(cy|test|testid|qa)$'],
          }
        : undefined,
  },
}

 

이제 노출되던 테스트용 id 들이 사라졌습니다.

 

📌 병렬 테스트

Cypress 에서 병렬 처리를 하려면 Cypress Clound(유료) 를 이용하거나

다른 패키지(sorry-cypress 등등)를 함께 이용해야합니다.

저는 이번 위클리에서는 로컬에서만 간단하게 동작하는걸 구현해보고 싶어서

Node.js 의 child_process 를 활용한 스크립트를 작성해봤는데.. 아직 제대로 동작은 안하네요.

(오히려 테스트 수행시간이 더 오래 걸리네요 😅)

 

const CYPRESS_ROOT_PATH = './cypress/integration'
const WORKLOAD = 2
const SPEC_FILE_REGEX = /.*?\.spec\.(js|ts)/

async function main() {
  const testSuitePaths = deriveTestSuitePaths()
  const jobs = allocateJobs(testSuitePaths)

  await runTestGroup(jobs)
}

async function runTestGroup(jobs) {
  const label = '🚀 total execution time'

  try {
    console.time(label)
    await Promise.all(jobs)
  } catch (error) {
    console.error(`❌ test failed : ${error.message}`)
  } finally {
    console.timeEnd(label)
  }
}

function allocateJobs(testSuitePaths) {
  const tasks = new Map()

  const groupedJobs = chunk(testSuitePaths, WORKLOAD)
  groupedJobs.forEach((group, idx) => tasks.set(idx, group))

  return [...tasks.entries()].map(([key, task]) => process(key, task))
}

async function process(key, testSuites) {
  const testOption = {
    command: 'cypress:headless',
    option: '--spec',
    specs: testSuites.join(','),
  }

  return new Promise((resolve, reject) => {
    const child = spawn('npm', [
      'run',
      testOption.command,
      '--',
      testOption.option,
      testOption.specs,
    ])

    child.stdout.on('data', (data) => {
      // 현재 수행중인 테스트 케이스 출력
    })

    child.on('exit', (code) => {
      const hasException = code > 0

      if (hasException) {
        reject(new Error(`exception occur at child process with code ${code}`))
      }
      resolve(true)
    })
  })
}

 

그래도 시간될때 조금씩 만들어서 CI 환경에서도 사용할 수 있는 패키지를 배포까지 해보려고 합니다. (올해안에..?)

 

📌 테스트 코드 커버리지

Cypress 를 활용한 E2E 테스트시에도 code coverage 를 확인할 수 있습니다.

이때 code instrument(코드 계측) 과정이 선행되어야하는데, 이는 Cypress 에서 별도로 제공해주지 않기에 별도로 직접 해야합니다.

가장 유명한 것은 istanbul 이라는 패키지를 활용하는 방법인데, 아쉽게도 안정화된 Babel 버전은 Next 12 이상부터는 더이상 유효하지 않기 때문에 그 대신 swc 에 대응해서 나온 실험적인 플러그인을 사용해야합니다.

(기존 babel-plugin-istanbul 의 모든 기능을 제공하지는 않습니다.)

 

원래는 공식 플러그인으로 들어가려고 테스트 단계에 들어갔는데,

실 사용자가 많이 않아서 그런지 추후 지원으로 변경되었더라구요.

feat(next/swc): support experimental coverage instrument by kwonoj · Pull Request #36692 · vercel/next.js

feat(next/swc): support experimental coverage instrument by kwonoj · Pull Request #36692 · vercel/next.js

 

⭐️ 적용 방법

> npm i -D swc-plugin-coverage-instrument

 

npm script 에 COVERAGE 를 true 로 넘겨줄 경우에만 intrument 과정을 수행할 수 있도록 플러그인을 할당합니다.

 

// next.config.js

module.exports = {
    experimental:
    process.env.COVERAGE === 'true'
      ? {
          swcPlugins: [['swc-plugin-coverage-instrument', {}]],
        }
      : undefined,
}

instrument 과정을 마치면, 코드 참조 정보가 전역 window 객체에 __coverage__ 라는 이름으로 추가됩니다.

해당 플러그인을 추가하고 dev 서버를 실행해서 빌드된 결과물을 확인해봅시다.

 

 

external module 부터 app code 까지 참조 정보가 추가된 것을 확인할 수 있습니다.

(babel plugin 은 external module 은 제외할 수 있는 방법이 있는데, swc plugin 버전은 제공해주는 기능에 한계가 있네요)

 

테스트 시에 code coverage 정보를 추출하기 위해서는 Cypress 에서 제공하는 @cypress/code-coverage 라는 패키지를 추가해줘야합니다.

 

npm install -D @cypress/code-coverage

 

cypress.config.js 파일에서 해당 패키지를 e2e 테스트 시에 불러올 수 있도록 수정합니다.

 

// support/e2e.ts
import '@cypress/code-coverage/support'

// support/index.ts
import './e2e'

// cypress.config.js
module.exports = defineConfig({
  e2e: {
    setupNodeEvents(on, config) {
      require('@cypress/code-coverage/task')(on, config)
      // NOTE: include any other plugin code

      return config
    },
  },
})

 

그리고 cypress 실행 시 coverage 옵션을 함께 넘겨주면 plugin 사용 여부를 제어할 수 있습니다.

 

"cypress:headless:coverage": "cypress run --env coverage=true"

 

이 패키지를 사용하면 테스트 이후 생성된 code coverage 정보를 HTML 파일로 생성해서

검색을 통해 원하는 컴포넌트만 확인할 수 있습니다.

다음은 항공 국제선 E2E 테스트 커버리지 결과물입니다.

 

 

각각의 파일에 대해서 테스트코드 추가가 필요한 부분이나 놓친 부분을 시각적으로 확인할 수 있습니다.

 

 

이런 coverage 정보도 CI 시 github artifact 에 함께 업로드하면 좋을 것 같은데..

이 플러그인은 현재 유지보수가 활발하지 않고, 보고된 이슈 중에 Next 13 의 /app 디렉토리와 함께 사용 시

앱 사용에 문제를 일으킨 사례가 보고된 것이 있어서 안정화되기전까지는 로컬 환경에서만 사용하는게 좋을 것 같습니다.

 

📌 트러블 슈팅

1️⃣ 가끔 예상치 못하게 테스트 실패하는 경우

가끔 예상치 못한 이유 (네트워크 이슈, API, 렌더링 속도 등) 으로 인해 테스트가 실패하는 경우가 있습니다.

이러한 변수를 최소한으로 줄여주기 위해 몇가지 설정을 추가해서 진행했습니다.

 

1. next-build 된 파일로 CI 에서 테스트 진행하기

로컬에서는 개발서버에서 동작하는 앱으로 테스트를 하지만

CI 환경에서는 build 를 통해 최적화된 코드로 수행될 수 있도록 합니다.

"e2e:headless": "start-server-and-test testdev-withmocks http://localhost:3000/air cypress:headless",
"e2e:ci": "start-server-and-test start-withmocks http://localhost:3000/air cypress:headless",

 

2. 이벤트 로깅 blocking

테스트 단계에서는 불필요한 network 요청을 막기 위해 이벤트 로깅 관련 요청을 막도록 설정을 추가했습니다.

// cypress.config.js

const { defineConfig } = require('cypress')

module.exports = defineConfig({
  // ...
  blockHosts: '*.google-analytics.com',
})

 

3. visit, location 이동 시 timeout 부여

페이지에 진입하거나 이동할 때 API 호출 등에 시간이 소요되어 테스트가 실패하는 경우가 간헐적으로 있어 기본 timeout 값인 4s 보다 크게 설정해줬습니다.

 

4. test-retries 설정 추가

기본적으로 테스트 실패시에 재시도를 하지 않지만 설정을 통해 변경할 수 있습니다.

runMode 와 openMode 에 각각 설정해줄 수 있는데,

CI 시 headless 하게 수행되는 cypress run 에 적용될 수 있도록 해줬습니다.

 

// cypress.config.js

const { defineConfig } = require('cypress')

module.exports = defineConfig({
  // ...
  retries: {
    runMode: 2,
  },
})

 

2️⃣ 세션 처리 어떻게 하지

항공은 별도의 테스트용 계정이 없다고 합니다.

세션과 엮여있는 동선은 어떻게 할지 고민하다가 테스트 수행 전 쿠키 설정하는 것으로 우회를 했습니다.

쿠키 사용시 주의할점은 cypress 는 일관된 상태를 위해 각각의 test 사이에 쿠키를 지운다는 것입니다.

테스트 사이에 세션을 유지하고 싶다면 cy.session 을 활용하면 됩니다.

 

📌 더 생각해보기

mock 데이터를 사용하는 이상, 서버 interface 가 바뀌면 mock 데이터도 변경이 필요하기 때문에 하나의 유지보수 포인트가 된다고 볼 수 있습니다.

이를 자동화 할 수 있는 방법은 없을까? 고민이 필요합니다.

→ 테스트의 안정성을 위해 데이터의 멱등성이 보장되어야할텐데, side effect 는 없을지 검증이 필요할 것 같습니다.

 

사실 현재 항공웹에서 가장 골칫거리는 예외 처리 동선입니다. (검색키 만료, 가격 변동, 유효기간 만료 등등)

지금은 Happy Path 만 추가했는데, 이러한 예외 동선도 테스트 케이스에 함께 추가해주는게 좋을 것 같습니다.

→ network intercept 이후 강제로 실패처리시키면 동선 테스트가 가능할 것 같습니다.

 

📌 마무리

 

 

러프한 E2E 테스트 방식을 도입해봤는데요, 이번 국제선 E2E 테스트를 통해서 반복되는 작업으로 인한 트리플 비즈프론트 개발자들의 피로도가 조금이나마 줄어들었으면 하는 희망과 함께 이번 포스트를 마치겠습니다.

 

긴 글 읽어주셔서 감사합니다.🙇‍♂️