📖 TIL - 테스트 라이브러리 핵심 정리

📌 문제 설명

문제 설명

프론트엔드 개발에서 테스트 코드 작성 시 필요한 다양한 테스트 라이브러리 함수들과 개념을 정확히 이해하고 활용해보자.

실제로 Auto-Summary-AI 프로젝트를 개발하면서 테스트 라이브러리를 처음부터 끝까지 적용해보는 경험을 했다. 노트 작성, 편집, AI 요약 기능까지 포함된 복잡한 웹 애플리케이션에 테스트 코드를 작성하면서 많은 시행착오와 깨달음을 얻을 수 있었다.

관련 프로젝트: Auto-Summary-AI

학습 목표

• Vi.js의 모킹 함수들 (vi.fn, vi.mock) 실전 활용
• React Testing Library의 다양한 쿼리 함수들 상황별 적용
• 테스트 환경에서의 라우터 설정 방법 완전 정복
• Jest/Vitest의 matcher 함수들을 통한 정교한 검증

---

🤔 문제 접근

실제 프로젝트에서 테스트를 구현하면서 부딪힌 주요 과제들:

🏗️ 복잡한 환경 구성

• RTK(Redux Toolkit) 상태 관리
• redux-persist를 통한 로컬 스토리지 연동
• React Router의 동적 라우팅
• OpenAI API 연동 및 비동기 처리

🎯 핵심 테스트 대상

• 노트 생성/편집 플로우
• 라우터 기반 페이지 이동
• AI 요약 기능의 유효성 검사
• 사용자 상호작용 (클릭, 입력, 폼 제출)

---

💡 해결 방법

🔧 모킹(Mocking) 전략

테스트 환경의 한계를 극복하기 위한 다양한 모킹 기법을 활용했다.

🏗️ 테스트 구조화

복잡한 기능을 체계적으로 테스트하기 위한 구조 설계

🛣️ 라우터 테스트 환경

실제 브라우저 없이도 라우팅을 완벽하게 테스트할 수 있는 방법 구축

---

🔍 코드 설명

실제 Auto-Summary-AI 프로젝트에서 겪은 경험들

🎪 테스트 환경의 현실적 제약과 해결책

가장 큰 난관: RTK + redux-persist 조합에서의 localStorage 문제

프로젝트에서 사용자의 노트를 브라우저에 저장하기 위해 redux-persist를 활용했는데, 테스트 환경에서는 실제 브라우저 환경이 아니라서 localStorage를 사용할 수 없다는 걸 뒤늦게 깨달았다. 😅

해결 과정에서 가장 헷갈렸던 부분: getItem에서 Promise.resolve(null)을 반환해야 한다는 점이었다. setItem/removeItem은 단순히 동작만 모킹하면 되지만, getItem은 실제로 값을 반환하는 함수이기 때문에 초기 상태에서는 null을 반환하도록 설정해야 한다는 걸 시행착오를 통해 학습했다.

// 브라우저 전역 함수 모킹 (알림 기능 테스트용)
window.alert = vi.fn();

// HTTP 클라이언트 전체 모킹
vi.mock("axios");

// OpenAI API 응답 모킹 - 실제 API 응답 구조 그대로 재현
vi.spyOn(api, "fetchOpenAI").mockResolvedValueOnce({
  choices: [{ message: { content: "AI가 생성한 요약 내용" } }]
});

// redux-persist용 스토리지 모킹 (핵심 포인트!)
const mockStorage = {
  getItem: vi.fn(() => Promise.resolve(null)), // 초기값 null 반환이 핵심
  setItem: vi.fn(() => Promise.resolve()),     // 저장 동작만 모킹
  removeItem: vi.fn(() => Promise.resolve())   // 삭제 동작만 모킹
};

🔍 DOM 요소 탐색의 실제 활용 패턴

프로젝트 특성: 같은 기능의 버튼이 여러 곳에 배치됨 (헤더, 사이드바 등)

// 실제 사용 패턴: 구조분해할당으로 필요한 쿼리만 추출
const {getAllByText, getByTestId, getByText, getAllByTestId} = render(
  <Provider store={testStore}>
    <PersistGate loading={<div data-testid="loading">Loading...</div>} persistor={persistor}>
      <RouterProvider router={router}/>
    </PersistGate>
  </Provider>
);

// PersistGate 로딩 완료까지 대기 (redux-persist 특성상 필수)
await waitFor(() => {
  expect(screen.queryByTestId("loading")).not.toBeInTheDocument();
}, { timeout: 3000 });

// Code Splitting으로 인한 lazy loading 대기
await waitFor(() => {
  expect(screen.queryByText("loading...")).not.toBeInTheDocument();
}, { timeout: 5000 });

👆 사용자 행동 시뮬레이션의 현실적 접근

실제 사용자 플로우: 노트 작성 버튼 클릭 → 페이지 이동 → 내용 입력 → 요약 생성 → 저장

// 현실적인 문제: "노트 작성" 버튼이 여러 개 존재
const noteButtons = getAllByText("노트 작성");
expect(noteButtons).toHaveLength(2); // 헤더와 사이드바에 각각 존재
await userEvent.click(noteButtons[0]); // 첫 번째(헤더) 버튼 클릭

// 실제 사용자처럼 기존 내용 지우고 새로 입력
const titleEl = getByTestId('title');
await userEvent.clear(titleEl);
await userEvent.type(titleEl, "테스트용 제목");

// textarea가 여러 개인 경우 (원본 내용, 요약 내용)
const contentEl = getAllByTestId('content');
await userEvent.clear(contentEl[0]);
await userEvent.type(contentEl[0], "30자 이상의 충분히 긴 테스트 내용입니다. AI 요약을 위해 작성한 예시 텍스트입니다.");

🛣️ 동적 라우팅 검증의 실제 케이스

프로젝트 특징: UUID 기반 동적 노트 페이지 (/notes/12345678-1234-1234-1234-123456789abc)

// 노트 생성 후 자동으로 해당 노트 페이지로 이동되는지 확인
await waitFor(() => {
  expect(router.state.location.pathname).toMatch(/^\/notes\/[a-f0-9-]{36}$/)
});

// 노트 저장 후 홈으로 리다이렉트되는지 확인
await waitFor(() => {
  expect(router.state.location.pathname).toBe('/')
});

🏪 Redux 상태 직접 검증

RTK의 장점 활용: testStore.getState()로 상태 직접 접근

// 노트가 실제로 Redux 스토어에 저장되었는지 확인
await waitFor(() => {
  const notes = testStore.getState().notes.lists;
  expect(notes).toHaveLength(1);
  expect(notes[0].title).toBe("테스트용 제목");
  expect(notes[0].content).toBe("30자 이상의 충분히 긴 테스트 내용입니다...");
  expect(notes[0].summary).toBe("AI가 생성한 요약 내용");
});

🎭 실제 비즈니스 로직 검증

프로젝트의 핵심 유효성 검사: 30자 미만은 요약 불가

// 비즈니스 룰에 따른 분기 처리
if (contentEl[0].value.length < 30) {
  expect(window.alert).toHaveBeenCalledWith('요약하려면 최소 30자 이상 입력해주세요.');
} else {
  expect(window.alert).not.toHaveBeenCalledWith('요약하려면 최소 30자 이상 입력해주세요.');
}

// 요약 생성 여부에 따른 저장 가능성 검증
if (window.alert.mock.calls.length > 0) {
  expect(window.alert).toHaveBeenCalledWith('요약 버튼을 클릭하여 요약 결과를 정리해주세요.');
} else {
  // 모든 검증이 통과한 경우의 성공 시나리오
}

---

✨ 새롭게 배운 점

🔧 모킹의 실전 활용법

vi.fn() vs vi.mock()의 명확한 차이: 개별 함수는 vi.fn(), 모듈 전체는 vi.mock()으로 처리

🔍 상황별 쿼리 선택 전략

• getByText: 반드시 존재해야 하는 요소 (없으면 테스트 실패로 처리)
• queryByText: 존재 여부를 확인하고 싶은 요소 (로딩 상태 등)
• findByText: 비동기로 나타나는 요소 (API 응답 후 렌더링)

🛣️ 메모리 라우터의 진가

createMemoryRouter의 핵심 가치: 브라우저 환경 없이도 완전한 라우팅 테스트 가능

📏 요소별 검증 매처 선택

실전 경험: input/textarea는 toHaveValue, 일반 텍스트 요소는 toHaveTextContent

🏗️ 복합 환경에서의 초기화 중요성

Redux + Router + PersistGate: 각 라이브러리의 초기화 순서와 방법이 테스트 성공의 핵심

🎯 실무에서 유용한 고급 기법들

• 정규표현식: UUID 같은 동적 값 검증에 toMatch() 활용
• 조건부 테스트: mock.calls.length로 함수 호출 여부 판단 후 분기
• 타임아웃 차등화: lazy loading(5초), 일반 비동기(3초)로 상황에 맞게 조절

---

🚀 실전에서 터득한 효율적인 패턴들

🔄 테스트 간 격리의 완벽함

beforeEach/afterEach 황금 조합:

• beforeEach: 모킹, 스토어, 라우터 전체 재설정
• afterEach: persistor.purge()로 영속 상태까지 완전 초기화

📝 코드 가독성 향상 기법

구조분해할당의 위력: render 반환값에서 실제 사용할 함수들만 선별적으로 추출

⏰ 현실적인 대기 시간 전략

상황별 타임아웃 설정:

• Code Splitting 로딩: 5초
• 일반 상태 변경: 3초
• 즉시 반영 예상: 1초

🎯 모든 시나리오 커버링

조건부 테스트의 힘: 성공/실패 케이스를 모두 고려한 분기 처리로 견고한 테스트

🔍 다층적 검증 체계

• UI 레벨: 화면에 올바르게 표시되는가?
• 상태 레벨: Redux 스토어에 정확히 저장되는가?
• 라우팅 레벨: 페이지 이동이 올바르게 일어나는가?
• 비즈니스 로직 레벨: 도메인 규칙이 정확히 적용되는가?

---

⭐️ 참고 자료

• Vitest 공식 문서
• React Testing Library 공식 문서
• Jest Matchers 문서
• Auto-Summary-AI 프로젝트 - 실제 테스트 코드 확인 가능