프론트엔드 테스트 도구 ( MSW, Vitest, React Testing Library )

1. MSW 방식의 mocking 서버 구현

• feat.md 에 따라서 개발진행.
• 동작 체크~
  • 서버 실행
  • service worker 기반 응답 확인
    
• 구조 이해 및 MSW 학습

참고. Service Worker

• Service Worker 등록:
  • 시작코드, worker.start() 실행
  • mockServiceWorker.js 파일을 백그라운드 스레드에 등록
• 네트워크 가로채기
  • 모든 fetch 요청을 네트워크로 나가기 전에 가로챔.
  • 가로챈 요청(URL, 메서드)을 handlers.js에 정의된 Mock 목록과 비교하여 일치하는 핸들러 찾기
  • 일치시 : 실제 서버 통신 없이 핸들러에 정의된 Mock 데이터(JSON)를 즉시 생성
  • 불일치 : 요청을 bypass하여 통과
• Service Worker는 이 Mock 응답을 웹 페이지의 fetch 호출 지점으로 반환

---

2. 단위테스트와 통합테스트

소프트웨어 테스트 단계

• 추가로 E2E 테스트
  • FE : 브라우저 또는 headless 브라우저 기반 동작 테스트
  • BE: API 요청과 응답 테스트

2.1 테스트의 대상 선정

• TodoAPP을 어떻게 테스트 할까? 뭘 테스트 해야할까?
• TodoAPP ? TodoInput? TodoList? Hook?

2.2 단위 테스트와 통합테스트

단위 테스트 (Unit Test)통합 테스트 (Integration Test)

정의	개별 컴포넌트/함수를 독립적으로 테스트	여러 컴포넌트가 함께 동작하는지 테스트
범위	하나의 컴포넌트/함수	여러 컴포넌트 + 의존성
실행 속도	빠름 (수 ms)	상대적으로 느림
목적	개별 로직의 정확성 검증	통합된 동작 검증(전체 시스템 레벨까지)
모킹	외부 의존성 모킹	최소한의 모킹 (실제 동작 유사)
실패 시 원인	명확함 (해당 컴포넌트)	파악 필요 (여러 요소 중 하나)
유지보수	쉬움	상대적으로 어려움
신뢰도	부분적 신뢰	높은 신뢰 (실제 사용 패턴)

2.3 단위 테스트 설계 원칙

• 독립성
  • 각 테스트는 다른 테스트에 영향을 주지 않아야함.
  • mock 을 활용해서 외부 의존성 제거
• 명확성
  • 테스트 이름만 봐도 무엇을 검증하는지 알 수 있어야 함
  • 하나의 테스트는 하나의 동작만 검증
• 순수성(반복가능성)
  • 같은 입력은 항상 같은 결과를 반환
  • 외부 환경(시간, 랜덤, 네트워크)에 의존하지 않음
• 빠른 실행
  • 개발자가 쉽게 자주 테스트 할 수 있어야함.

2.4 단위 컴포넌트 테스트 전략

하나의 컴포넌트 -> 하나의 단위 테스트와 비슷

• 단위 테스트는 의존성이 없는 독립적인 대상이 적절
  • TodoInput
  • TodoList
• TodoInput 에서는 어떤테스트를 해야할까?
  • TodoInput 의 역할은 무엇인가?
    • Props 를 받아서 동작
    • 사용자 인터랙션 검증
    • 입력값 검증 로직 확인
  • 역할 기반으로 테스트 코드 구현을 부탁한다.
  • 코드 이해하기.
• TodoList 의 역할은?
  • Props 변경에 따른 UI 변화
  • 데이터 렌더링
  • 조건부 렌더링(로딩이 있다면, 빈목록은 ?)
• useFetch
  • API 호출 잘 되나?
  • 상태관리 확인
  • fetch API 모킹 또는 MSW 연동방식
• TodoApp 테스트 해야하나?
  • 통합 테스트
  • 전체 플로우 동작 확인
  • 컴포넌트 간 상호작용 확인

---

3. Vitest와 React Testing Library

Vitest와 React Testing Library (RTL)를 사용해서 구현하는 것이 현재의 주류 중 하나

3.1. Vitest: (Test Runner)

Vitest는 Vite 기반의 빠르고 효율적인 테스트 러너로, Jest의 API를 완벽하게 지원한다. Jest의 API와 동일하게 사용하여 테스트 실행 환경과 검증 기능을 제공한다.

(예전에는 Mocha, QUnit, Karma 등이 있었음)

기능역할예시 코드

테스트 정의	테스트 케이스와 그룹을 정의한다.	test('설명', () => {})
검증 (expect)	특정 값이 기대하는 값과 일치하는지 확인한다.	expect(value).toBe(1)
Mocking	함수나 모듈의 실제 동작을 대체하여 격리한다.	const mockFn = vi.fn()
비동기 처리	비동기 코드가 완료될 때까지 기다린다.	test('...', async () => {})

3.2. React Testing Library (RTL)

RTL은 컴포넌트를 렌더링하고 사용자처럼 상호작용하며 DOM을 검색하는 유틸리티 세트다.

RTL의 목표: "사용자가 실제로 보는 방식대로 테스트하라"

기능역할예시 코드

렌더링	테스트 환경에 컴포넌트를 렌더링한다.	render()
DOM 쿼리	사용자가 보는 방식으로 요소를 검색한다.	screen.getByRole('button')
사용자 이벤트	실제 사용자의 키보드 입력, 클릭 등을 시뮬레이션한다.	await userEvent.click(element)

3.3. 설치 및 설정

• vitest, jsdom, c8 등의 모듈을 설치하고
• vite.config.ts 파일에 테스트 환경(예: globals: true, environment: 'jsdom')을 설정

3.4 테스트 구조

실제 테스트 코드를 작성하기 전에, Vitest/Jest와 같은 테스트 프레임워크가 요구하는 테스트 파일의 기본 구조와 각 키워드의 역할을 먼저 이해하기.

1. describe: 테스트 그룹화 (Grouping)

• 관련된 테스트들을 논리적으로 묶어주는 함수. 일반적으로 테스트 대상 컴포넌트나 모듈의 이름으로 사용

describe('TodoInput 컴포넌트 테스트', () => {
    // 여기에 모든 test() 함수들이 들어감
});

2. test 또는 it: 개별 테스트 케이스 (Test Case)

• 실제로 코드를 실행하고 검증(Assertion)을 수행하는 가장 작은 단위
• 하나의 test는 하나의 독립적인 시나리오만 검증하는 것이 좋음
• 테스트의 이름은 "무엇을 했을 때 (When), 무엇이 되어야 한다 (Should)"와 같이 서술적으로 작성

test('사용자가 텍스트를 입력할 수 있다', async () => {
  // ..궁시렁 어쩌구 
});

// 'it'도 'test'와 완전히 동일한 기능.
it('버튼을 클릭했을 때 특정 함수가 호출되어야 한다', () => {
});

3. Given-when-then 방식의 테스트 케이스 구현

효율적이고 읽기 쉬운 테스트 코드를 작성하기 위해 Given-When-Then (GWT) 구조를 사용하는 것이 좋음.

이 패턴은 모든 테스트 케이스에 명확한 흐름과 목적을 부여함

• Given
  • 준비단계, 테스트에 필요한 초기 조건(렌더링, Mock 함수)을 설정
• When
  • 실행 단계, 테스트하려는 특정 행동(사용자 상호작용)을 실행
• Then
  • assertion, 실행 결과가 예상대로 나타났는지 expect로 확인

test('버튼 클릭 시 함수가 호출되어야 한다', async () => {
  // Given
  const mockOnAdd = vi.fn();
  render(<TodoInput onAddTodo={mockOnAdd} isLoading={false} />);
  
  // When
  await userEvent.click(screen.getByText('추가'));
  
  // Then
  expect(mockOnAdd).toHaveBeenCalled();
});

3. Setup/Teardown: 테스트 환경 준비와 정리

• 테스트가 실행되기 전후에 반복적으로 필요한 준비 작업(Setup)과 정리 작업(Teardown)을 처리
• 이는 테스트 간의 독립성(Isolation)을 유지하는 데 매우 중요

키워드실행 시점역할

beforeEach	각 test 함수 실행 직전	각 테스트가 독립적으로 실행되도록 초기 상태를 설정하거나 Mocking을 재설정. (가장 많이 사용됨)
afterEach	각 test 함수 실행 직후	각 테스트가 끝난 후 DOM을 정리(cleanup)하거나 Mocking 상태를 초기화.
beforeAll	describe 그룹 전체 시작 전	모든 테스트에 걸쳐 한 번만 필요한 전역 설정(예: MSW worker 시작)을 처리.
afterAll	describe 그룹 전체 종료 후	모든 테스트가 끝난 후 전역 자원(예: MSW worker 종료)을 해제

---

4. 구현하기 전 주요 개념들

4.1. 요소 검색 (DOM Query)

• 사용자가 접근할 수 있는 속성 (Role, Text, Label 등)을 기준으로 DOM 요소를 찾는다.
• getBy는 요소를 찾지 못하면 에러를 발생시키고, queryBy는 null을 반환

screen.getByRole('button');

4.2. 값 검증 (Assertion)

• 특정 값이나 요소의 상태가 기대하는 결과와 일치하는지 확인
• RTL의 커스텀 Matchers (toBeInTheDocument 등)와 Vitest/Jest의 기본 Matchers (toHaveValue, toBe 등)를 함께 사용

expect(input).toHaveValue('값');

4.3. 함수 호출 검증

• Mock 함수 (vi.fn())가 의도대로 호출되었는지, 그리고 호출 시 올바른 인자를 전달받았는지 확인

expect(mockFn).toHaveBeenCalledWith('hello');

4.4. 클릭 이벤트 (Interaction)

• 버튼 클릭, 체크박스 토글 등 마우스 상호작용을 실제 사용자처럼 시뮬레이션
• userEvent를 사용하는 것이 fireEvent보다 실제 브라우저와 유사하게 동작하므로 권장

await userEvent.click(button);

4.5. 키보드 입력 (Interaction)

• 텍스트 입력, 엔터 키, 탭 이동 등 키보드 상호작용을 시뮬레이션하며, onChange 이벤트와 입력 상태를 정확하게 반영

await userEvent.type(input, '텍스트');

4.6. 비동기 대기 (Asynchronous)

• API 응답, UI 업데이트, 상태 변경 등 비동기 작업이 완료되어 특정 조건이 충족될 때까지 테스트 환경을 대기

await waitFor(() => {
  expect(screen.getByText('결과')).toBeInTheDocument();
});

---

5. 리액트 컴포넌트 테스트 구현하기

• Input 컴포넌트
• 리스트 컴포넌트
• 커스텀 훅
  • 리스트가져오기, 추가하기, 500에러 대응하기
  • 모킹 vs. MSW
    • MSW를 쓰면 fetch 모킹을 제거하고 실제 fetch를 그대로 테스트하니까 더 깔끔하고 신뢰도도 높은편.

6. E2E 테스트(End to End)

• 실제 사용자가 서비스를 사용하는 것처럼 브라우저 환경 전체를 자동화하여 테스트하는 방식
• 가장높은 신뢰도
  • UI + Networking + Routing + DOM 렌더링
• 실제 브라우저에서 실행(chromium, webkit, firefox)
• 단위보다 느리지만 사용자 경험을 검증할 수 있음

FE 도구들

• Cypress, Playwright

Playwright 특징들

• DOM이 나타날때까지 자동으로 기다린다
• waitFor등 불필요. 네트워크 요청, 렌더링 자동감지
• DOM요소를 쉽게 찾는편.
• 스냅샵, 녹화(recorder)기능 제공.
• Codegen 으로 자동 테스트코드 생성.
• 테스트가 끝나면 자동으로 HTML 리포트를 생성
  • npx playwright show-report

playWright 실행순서

1. Playwright test runner 실행
2. 브라우저 자동 실행
3. 테스트 URL 접속
4. 사용자의 실제 동작을 시뮬레이션
5. DOM 상태 확인
6. 테스트 종료 및 브라우저 닫기
7. 결과 리포트 출력 (HTML 리포트 포함)

사용예시

브라우저 열기

const browser = await chromium.launch();

새로운 페이지(page)를 연다

const page = await browser.newPage();

특정 URL로 이동

await page.goto('http://localhost:5173/');

행동을 시뮬레이션

await page.fill('#todo-input', '장보기');
await page.click('button:has-text("추가")');

실제 DOM 상태를 확인

await expect(page.locator('li')).toContainText('장보기');

완료 후 브라우저 종료

await browser.close();

7. TDD

Test driven development

8. Code Coverage

• 테스트가 코드의 몇 %를 실행했는지 보여주는 수치
  • 예) 코드 커버리지 80% → 전체 코드 중 80%가 테스트 실행 중 실제로 수행됨
• 테스트가 충분히 작성되었는지 확인
• CI/CD에서 품질 기준으로 삼기 좋음

커버리지의 주요 유형

• 라인 커버리지(Line Coverage): 몇 줄이 실행됐는가
• 브랜치 커버리지(Branch Coverage): if/else 등 분기문이 각 조건마다 실행됐는가
• 함수 커버리지(Function Coverage): 함수들이 호출됐는가
• 스테이트먼트 커버리지(Statement Coverage): 실행 가능한 구문(statement)이 실행됐는가

주의점

• 커버리지가 높다고 테스트 품질이 높은 건 아님
• 중요한 로직만 잘 테스트했다면 커버리지가 낮아도 괜찮을 수 있음