현업에서의 테스트코드

강의의 마지막 세션에서는 현업에서 테스트코드라는 주제를 다루었다.

현업에서는 다양한 도구들을 활용하여 테스트코드를 작성하고 있는 것 같았다.

 

Cypress Cloud

 

Cypress Cloud는 Cypress에서 무료로 제공해주는 클라우드 서비스이다.

Cypress에 로그인만 하면 Cypress Cloud에 접근할 수 있다.

 

여러 단계를 거쳐서 로그인을 한 후 프로젝트를 하나 생성해주면

 

프로젝트 id 발급

 

위와 같이 프로젝트 ID를 발급받을 수 있다.

이 ID를 cypress.config.ts 파일에 명시해주면 된다.

 

export default defineConfig({
  projectId: "발급받은 프로젝트 ID",
  e2e: {
    setupNodeEvents(on, config) {
      // implement node event listeners here
    },
    baseUrl: "http://localhost:3000",
  },
  viewportWidth: 400,
  viewportHeight: 780,
});

 

최종 config 파일의 내용은 다음과 같다.

 

사실 시키는대로만 하면 된다.

프로젝트 ID를 추가했다는 체크 표시를 누르고 Next를 누르면

 

CI Provider 선택 창

 

CI Provider를 고르라는 창이 뜬다.

나는 Github Actions를 사용할 예정이므로 이를 클릭하고 Next를 눌러주었다.

 

Github 연동 매뉴얼

 

그러면 위와 같이 Github와 연동하기 위한 매뉴얼을 하나부터 열까지 다 짜주는 것을 확인할 수 있다.

 

Try it first에 나와있는 명령어를 로컬 서버를 구동시킨 후, 로컬에서 실행해보자.

 

성공한 테스트

 

그럼 위와 같이 터미널에서 성공했다고 로그를 띄워주게 되고,

 

Cypress Cloud에서 보여주는 테스트 성공 상태

 

Cypress Cloud에서도 테스트가 성공적으로 마친 것을 UI로 보여주는 것을 확인할 수 있다!

 

이제 프로젝트의 Github를 Cypress Cloud와 연결해주자.

위에서 얻은 매뉴얼 그대로 따라가면 된다.

 

우선 매뉴얼대로 CYPRESS_RECORD_KEY 를 Github의 secret(New Repository Secret)에 넣어주었다.

그 후, 매뉴얼에서 제공하는 Github Action 코드를 그대로 .github/workflows/cypress.yml 파일에 넣어주었다.

 

나는 refactor 브랜치에 해당 Github Action 코드를 넣어준 뒤 push 해주었다.

그러면 Github Action 코드가 push를 감지하고, 아까 넣어준 CYPRESS_RECORD_KEY 값을 자동화 과정에서 이용한다.

그러면 Cypress Cloud에서 해당 브렌치에서의 테스트 결과를 자동으로 확인할 수 있는 것이다.

 

다만 Github Action 코드를 내 프로젝트의 패키지 매니저인 Yarn에 맞게 약간 수정해주었다.

 

name: Cypress Tests
on: [push]
jobs:
  cypress-run:
    runs-on: ubuntu-latest
    # Runs tests in parallel with matrix strategy https://docs.cypress.io/guides/guides/parallelization
    # https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs
    # Also see warning here https://github.com/cypress-io/github-action#parallel
    strategy:
      fail-fast: false # https://github.com/cypress-io/github-action/issues/48
      matrix:
        containers: [1, 2] # Uses 2 parallel instances
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Install Dependencies
        run: yarn install
      - name: Cypress run
        # Uses the official Cypress GitHub action https://github.com/cypress-io/github-action
        uses: cypress-io/github-action@v6
        with:
          # Starts web server for E2E tests - replace with your own server invocation
          # https://docs.cypress.io/guides/continuous-integration/introduction#Boot-your-server
          start: yarn dev
          wait-on: "http://localhost:3000" # Waits for above
          # Records to Cypress Cloud
          # https://docs.cypress.io/guides/cloud/projects#Set-up-a-project-to-record
          record: true
          parallel: true # Runs test in parallel using settings above
        env:
          # For recording and parallelization to work you must set your CYPRESS_RECORD_KEY
          # in GitHub repo → Settings → Secrets → Actions
          CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }}
          # Creating a token https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

 

개발서버를 구동시키는 명령어인 yarn dev로 수정해주었고, 의존성들을 찾지 못하는 오류를 해결해주기 위해 이를 설치하는 과정을 추가해주었다.

 참고로 GITHUB_TOKEN은 우리가 secrets에 설정을 따로 해주지 않아도 된다. Github가 알아서 넣어주는 값이다.

 

merge전 테스트 체크

 

각 작업을 마친 뒤 refactor 브랜치에 push를 하고, develop 브랜치에 PR을 날리면 위와 같이 테스트가 병렬적으로 돌아가는 것을 확인할 수 있다.

 

통과한 테스트

 

모두 다 통과하고 위와 같이 모든 체크가 완료되었다는 UI가 뜨면 이제 안전하게 Merge할 준비가 된 것이다.

 

CI 동작 통과

 

actions 탭에서도 Cypress CI가 성공적으로 마친 것을 확인할 수 있고,

 

Cypress Cloud의 테스트 통과 UI

 

Cypress Cloud에도 테스트가 무사히 통과했다는 표시를 확인할 수 있다!

 

결국 해당 단계의 이점은 Merge 하려는 브랜치에서, 적어도 우리가 짜놓은 테스트와 관련된 기능에는 오류가 없을 것임을 확실시 할 수 있다는 점일 것이다.

통상적인 git flow에서 배포될 브랜치의 이전 브랜치에 해당 Github Action 코드를 넣어주면, 배포될 브랜치에 Merge하기 전에 모든 테스트 코드가 통과하는 것을 확인할 수 있으므로, 테스팅 목적으로 배포되어있는 브랜치에서 Cypress 테스트가 병렬적으로 돌아가게 하는 것이 가장 효율적일 것 같다고 생각된다.

 

AWS Amplify

 

AWS Amplify를 이용하면 프론트엔드는 무료로 배포할 수 있다고 한다.

 

프로젝트 저장소 선택

 

우선 프로젝트 작업이 진행된 도구를 선택하는 창이 나온다.

아마 대부분 Github를 활용할 것이라 생각된다. 나도 Github를 선택한 뒤 다음으로 넘어갔다.

 

자동으로 감지된 빌드 설정

 

그러면 위와 같이 해당 프로젝트의 빌드 설정들을 자동으로 감지해주는 것을 볼 수 있다.

 

환경변수 추가 섹션

 

그리고 해당 페이지의 밑에 고급 설정에서 사용하고 있는 환경 변수들을 추가해준 후 다음을 누르면 된다.

 

마지막 페이지는 지금까지 설정한 모든 단계들을 재확인 시켜주는 단계이다.

문제가 없다면 배포하기 버튼을 누른뒤 조금만 기다려 주면 끝이다.

 

배포 완료

 

위와 같이 배포가 성공적으로 된 것을 확인할 수 있다.

자동으로 설정된 도메인으로 들어가보면

 

배포된 페이지

 

성공적으로 페이지가 잘 뜨는 것을 볼 수 있다!

 

Amplify 에서의 테스트 자동화

 

이제 성공적으로 배포가 되었으니 앞으로의 배포에서 테스트가 자동적으로 이루어지게 설정해보자.

 

우선 

 

yarn add start-server-and-test

 

명령어를 통해 패키지를 설치해주자.

위 패키지는 프론트 개발 서버를 구동시킨 후 test를 자동화하는데에 쓰이게 된다.

 

"cypress-test": "cypress run",
"start-server": "yarn dev",
"ci": "start-server-and-test start-server http://localhost:3000 cypress-test"

 

그 후 나는 package.json의 scripts에 위 script들을 추가해준 후 push해 주었다.

그러면 yarn ci 명령어를 통해 개발 서버가 구동되고, cypress까지 실행시킬 수 있게 된다.

로컬에서 한번 명령어를 실행시켜보자.

 

로컬에서 실행한 ci 테스트

 

위처럼 개발 서버가 구동됨과 동시에 cypress test까지 잘 실행되는 것을 확인할 수 있다.

(그런데 해당 패키지를 실행하면 npm으로만 돌아가는 것 같다. yarn으로 바꿀 수 있는지는 의문이다.)

 

결국 해당 과정이 배포할 때 자동으로 돌아갈 수 있게끔 추가해주면 된다.

 

빌드 설정 수정 화면

 

Amplify의 빌드 설정으로 가면 amplify.yml 파일을 수정할 수 있다.

 

version: 1
frontend:
  phases:
    preBuild:
      commands:
        - yarn install --immutable
    build:
      commands:
        - yarn run build
  artifacts:
    baseDirectory: .next
    files:
      - '**/*'
  cache:
    paths:
      - .next/cache/**/*
      - node_modules/**/*
test:
  phases:
    preTest:
      commands:
        - yarn ci
    test:
      commands:
        - yarn ci
  artifacts:
    baseDirectory: cypress
    configFilePath: '**/mochawesome.json'
    files:
      - '**/*.png'
      - '**/*.mp4'

 

공식문서에서 제공해주는 test 과정에서 불필요한 부분들을 제외하고, 내 프로젝트의 명령어에 맞게만 수정해주었다.

 

재배포 페이지

 

저장 후 위 페이지에서 재배포를 실행한 후, 수정된 배포 로직을 봐보자.

 

설정해준 yarn ci 로직 실행

 

빌드 과정에서 package.json에 명시해 둔 ci 명령어가 실행되는 것을 확인할 수 있다!

 

cypress 테스트 완료

 

테스트까지 자동으로 실행시켜주는 것을 확인할 수 있다.

 

만약 테스트가 실패하게 되면 배포 과정도 건너뛰게 된다.

즉, 테스트가 통과해야만 배포가 되는 형식이라 안정성을 보장할 수 있다.

 

TDD (Test Driven Development)

 

TDD란 영어 그대로 테스트를 중심으로 개발을 진행하는 것을 말한다.

이전에 썼던 블로그도 그렇고, 우리가 진행하는 대부분의 프로젝트에서는 개발이 우선적으로 이루어진 후 안정화를 위해 테스트 코드를 작성하는 경우가 많을 것이다.

그러나 TDD 방식에서는 

 

1. 성공/실패 케이스를 작성한 테스트코드를 먼저 구현
2. 해당 테스트케이스에 맞게 코드 구현

위의 절차를 따라서 기획에 맞게 테스트케이스를 먼저 작성하고, 짜놓은 테스트케이스가 잘 돌아갈 수 있도록 실제 코드를 짜게된다.

 

사실 대부분의 경우에서 쓰이지 않는 방식이라고 생각하는데, 시간이 많고 극도로 안정적인 서비스여야만 하는 경우에는 TDD 방식이 더 효율적일 것이다.

 

TDD 방식을 도입하게 되면 우선 기획에 맞게 테스트 구조를 짜게된다.

 

describe("로컬 회원가입 화면", () => {
  it("사용자는 이메일, 비밀번호, 닉네임을 사용해서 가입한다.", () => {
    //given - 회원가입 페이지에 접근한다.
    //when - 이메일, 비밀번호, 닉네임을 입력한다 / 이메일과 비밀번호 형식이 정해놓은 형식과 일치한다
    //then - 회원가입 버튼이 활성화된다 / 버튼을 누르면 회원가입에 성공하고 가입 성공 페이지로 이동한다.
  });
});

 

예를들어 위처럼 회원가입 성공 케이스에 대한 로직을 정리한뒤 이에 맞게 우선 테스트 케이스를 작성한다.

그리고나서 실제 코드를 구현하며 테스트코드를 돌려봄으로써, 내가 구현한 코드가 기획 의도에 맞게 돌아가고 있는지 확신을 가지며 작업해 나갈 수 있다.

 

ChatGPT 활용법

 

ChatGPT가 등장하며 개발자들에게는 없어서는 도구가 되고있다.

이를 어떻게 사용하느냐가 개발의 효율에 큰 영향을 주기 때문에 올바른 사용법을 알아보았다.

 

컨텍스트를 최대한 자세히!

 

대충 질문을 던지면 사실 AI는 본인이 어떤 일을 해야하는지 명확히 모를 수 밖에 없고, 내가 원하는 답을 얻지 못할 확률이 매우 높다.

 

1. 너는 10년차 시니어 프론트엔드 개발자야.
2. 나는 주니어 프론트엔드 개발자이고, Cypress로 React.js 테스트코드를 작성하고 싶어.
3. 나는 '/register'라는 화면에 접근해서 테스트를 할거야.
4. 여기서 이메일, 비밀번호, 닉네임 input이 하나라도 채워지지 않은 경우를 테스트해줘.

 

위처럼 이른바 'role-playing'을 통해 컨텍스트를 GPT에게 최대한 자세히 던져주면 원하는 답을 얻을 확률이 올라갈 수 밖에 없을 것이다.

얻은 답변을 가져다가 본인의 코드에 맞게 약간씩만 수정해주면 처음부터 문법들을 다 찾아가며 작성하는 것 보다 작업 효율을 훨씬 높일 수 있다.

 

이처럼 실무에서 테스트코드를 사용하는 여러가지 방법에 대한 강의를 들어보았다.

프로젝트에서 테스트코드를 제대로 도입 하는게 현실적으로 가능한 것일까 의문이 들기도 하였지만, 추후 하게될 준비 과정 및 실무에서는 무조건 도움이 될 것이라고 생각한다!!

 

참고

 

https://learn.cypress.io/tutorials/deploying-to-vercel