Skip to main content Link Menu Expand (external link) Document Search Copy Copied
⚽️ TIL, 배운 것을 그때그때 기록하자

테스팅 시작하기

  1. 테스팅을 하는 이유 간단하게 더 안정적인 어플리케이션을 위해서는 여러 방법으로 테스트를 해줘야 더 안정적인 어플리케이션이 될 수 있습니다.

  2. 테스팅으로 얻는 이점

    • 디버깅 시간 단축, 만약 데이터가 잘못 나왔다면 그것이 UI의 문제인지 DB의 문제인지 등 전부 테스트를 해봐서 찾아야 하는데 테스팅 환경이 구축되어 있다면 자동화된 유닛 테스팅으로 특정 버그를 쉽게 찾아낼 수 있습니다.
    • 더욱 안정적인 어플리케이션, 많은 테스트 코드와 함께 작성된 코드의 어플리케이션이 되기 때문에 훨씬 안정적인 어플리케이션이 됩니다.
    • 이밖에도 재설계 시간의 단축, 추가로 무언가를 더 구현해야 할 때 더 용이하게 할 수 있습니다.

TDD란?

  • 실제 코드를 작성하기 전에 테스트 코드를 먼저 작성합니다.
  • 테스트 코드를 작성한 후 그 테스트 코드를 pass할 수 있는 실제 코드를 작성합니다.
  1. 원하고자 하는 기능의 테스트 코드 작성
  2. 테스트 실행 -> fail
  3. 테스트 코드에 맞는 실제 코드 작성
  4. 테스트 실행 -> pass

장점

  1. TDD로 인해 많은 기능을 테스트하기에 소스 코드에 안정감이 부여된다.
  2. 실제 개발하면서 많은 시간이 소요되는 부분은 디버깅 부분이기에 TDD를 사용하면 디버깅 시간이 줄어들고 실제 개발 시간도 줄어듭니다.
  3. 소스 코드 하나하나를 더욱 신중하게 짤 수 있기 때문에 깨끗한 코드가 나올 확률이 높습니다.

React Testing Library란

DOM Testing Library + React 컴포넌트 작업을 위한 API를 추가한 것 즉, React 컴포넌트를 테스트하는 가벼운 솔루션

DOM Testing Library란 DOM 노드를 테스트하기 위한 매우 가벼운 솔루션입니다.

CRA로 생성된 프로젝트는 React Testing Library를 지원합니다. 그렇지 않은 경우 다음과 같이 추가할 수 있습니다. npm install --save-dev @testing-library/react

  • Enzyme: 구현 주도 테스트
  • RTL: 행위 주도 테스트(사용자 입장)

DOM 이란

Document Object Model: XML, HTML 문서의 각 항목을 계층으로 표현하여 생성, 변형, 삭제할 수 있도록 돕는 인터페이스입니다. 즉, HTML 요소들의 구조화된 표현입니다.

DOM은 HTML이 브라우저의 렌더링 엔진에 의해 분석되고 분석이 모두 끝나고난 HTML 파일이 DOM입니다.

HTML은 화면에 보이고자 하는 모양과 구조를 문서로 만들어서 단순 텍스트로 구성되어 있으며 DOM은 HTML 문서의 내용과 구조가 객체 모델로 변환되어 다양한 프로그램에서 사용될 수 있습니다.

HTML 문서가 유효하지 않게 작성됐을 때는 브라우저가 올바르게 교정해주며, DOM은 Javascript에 의해 수정될 수 있습니다. 하지만 HTML은 수정하지 않습니다.

웹페이지 빌드 과정(Critical Render Path)

브라우저가 서버에서 페이지에 대한 HTML 응답을 받고 화면에 표시하기 전에 여러 단계가 있습니다. 웹 브라우저가 HTML 문서를 읽고, 스타일 입히고 뷰포트에 표시하는 과정입니다.

  1. 문서를 읽어들여서 그것들을 파싱하고 어떤 내용을 페이지에 렌더링할 지 결정합니다.(HTML, CSS) + JavaScript
  2. Render Tree: 브라우저가 DOM과 CSSOM을 결합하는 곳이며, 이 프로세스는 화면에 보이는 모든 콘텐츠의 콘텐츠와 스타일 정보를 모두 포함하는 최종 렌더링 트리를 출력합니다. 즉, 화면에 표시되는 모든 노드의 콘텐츠 및 스타일 정보를 포함합니다.
  3. Layout: 브라우저가 페이지에 표시되는 각 요소의 크기와 위치를 계산하는 단계입니다.
  4. Paint: 페인트 단계에 도달하면 브라우저는 레이아웃 결과를 선택하고 픽셀을 화면에 페인트해야 합니다.

Mock Service Worker

백엔드에서 데이터를 가져오는 부분을 테스트하기 위해서는 실제로 서버에 호출하는 end-to-end 테스트를 할 수 있지만 서버에 요청을 보낼 때 그 요청을 가로채서 Mock Service Worker라는 것으로 요청을 처리하고 모의 응답(mocked response)을 보낼 수 있습니다.

작동 방식 브라우저에 service worker를 등록하여 외부로 나가는 네트워크 요청을 감지합니다. 그리고 그 요청을 실제 서버로 갈 때 중간에 가로채서 MSW 클라이언트 사이드 라이브러리로 보냅니다. 그 후 등록된 핸들러에서 요청을 처리한 후 모의 응답을 브라우저로 보냅니다.

방법 2가지

  • 브라우저와 통합
    • 서비스 워커 생성
    • 생성한 서비스 워커 브라우저에 등록
    • 등록 확인
  • 노드와 통합(Jest 사용하는 테스트 환경)
    • 서버 생성
    • API mocking 설정

위 방법의 공통점

  • msw 설치
  • 핸들러 생성
  • 핸들러 type 지정(rest 혹은 graphql)
  • rest(Rest API)의 경우 http method 지정
  • req(요청 정보), res(모의 응답 생성), ctx(모의 응답의 상태 코드, 헤더, 본문 설정)