GitHub Actions란

리포에 정의된 워크플로우를 통해 코드의 빌드, 테스트, 배포를 자동화 하는 도구. 프로젝트 내부 .github/workflows 경로에 작성된 yaml파일을 읽고 실행한다.

# vitest.yml
name: 'vitest test'
on: pull_request
jobs:
  Component-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0
      - uses: actions/setup-node@v3
        with:
          node-version: 19
      - name: Install dependencies
        run: npm ci
      - name: run vitest
        run: npm run test

on: pull_request: 풀리퀘스트가 발생하거나, 해당 PR에서 커밋이 발생할 때마다 이 액션이 실행된다.

1부 마무리

테스트 코드의 효과

첫 수업부터 강조한 우리가 테스트 코드를 공부해야 하는 이유 :

• 리팩토링 - 코드에 대한 빠른 피드백을 바탕으로 안정적으로 리팩토링을 진행할 수 있다.
• 문서 - 테스트 코드 자체가 앱의 이해를 돕는 문서가 된다.
• 좋은 설계 - 테스트 하기 좋은 코드가 좋은 코드다. 그래서 테스트 단위에 대한 고민은 좋은 코드 설계로 이어진다.

테스트 코드 작성 규칙

• 인터페이스 기준으로 테스트를 작성
  • 내부 구현에 대한 의존성이 없어야 한다.
  • 그래서 리액트 컴포넌트의 state 같은 내부 데이터를 직접 조작하기보다 사용자 이벤트나 UI를 기준으로 작성한다.
• 의미 있는 테스트인지 고민하자
  • 커버리지 100%에 집착하기보다 유의미한 기능을 검증할 수 있는지 확인
• 테스트 코드의 가독성을 생각하자
  • 명확한 테스트 설명
  • 테스트코드도 하나의 책임을 가진다.

단위 테스트

앱에서 테스트 가능한 가장 작은 소프트웨어가 예상대로 동작하는지 확인하는 테스트

• 공통 컴포넌트
• 리액트 훅
• 유틸 함수

통합 테스트

두 개 이상의 모듈이 상호 작용하여 발생하는 상태를 검증하는 테스트.

• 비즈니스 로직을 기준으로 도메인별로 나누어 해당 도메인에 참여하는 컴포넌트들의 조합을 검증.
• 상태 관리, API 호출은 상위 컴포넌트로 응집.

키워드

• 테스트 프레임워크
• 단언 assertion
• 매처 matcher
• 셋업, 티어다운
• Testing Library
• 모킹
• msw

테스트의 한계

모든 테스트들은 장점과 한계를 가진다. 그래서 프로젝트의 성격에 따라 어떤 테스트에 더 시간가 자원을 사용해야 하는지 결정하는것이 중요하다. 대체로 일반적인 서비스 앱의 경우 통합 테스트에 집중하는 것이 좋고, 공통 컴포넌트나 리액트 훅과 같은 UIKit를 만드는 프로젝트에서는 단위 테스트에 집중하는 것이 좋다.