Vitest Mocking 전략 최적화를 통한 테스트 격리 및 의존성 제어 설계

Vitest Mocking: vi.mock vs vi.spyOn Explained

Manas Joshi2026년 4월 12일9분intermediate

AI 요약

Context

외부 API 및 DB 커넥터와 같은 Side Effect 발생 모듈의 직접 호출로 인한 테스트 불안정성 및 실행 속도 저하 발생. 모듈 전체 교체와 특정 메서드 관찰이라는 서로 다른 격리 수준에 대한 체계적인 선택 기준 필요.

Technical Solution

Module-level Isolation을 위해 vi.mock을 활용한 모듈 전체 대체 및 Factory 함수 기반의 Mock 구현체 주입
Partial Mocking 구조 설계를 위해 importOriginal()을 통한 원본 모듈 유지 및 특정 Export 함수만 선택적 오버라이딩
Method-level Inspection을 위해 vi.spyOn으로 기존 객체의 메서드를 래핑하여 호출 인자와 횟수를 추적하는 관찰 구조 설계
TypeScript 타입 안정성 확보를 위해 vi.mocked 헬퍼를 통한 Mock 함수 전용 타입 추론 적용
Test Leakage 방지를 위해 spyOn 사용 후 mockRestore()를 통한 원본 메서드 복구 프로세스 강제
Hoisting 특성을 고려하여 vi.mock 선언부를 Import 문보다 상단에 배치하는 실행 순서 제어

실천 포인트

- 외부 라이브러리 전체를 대체해야 하는가? → vi.mock 사용 - 기존 객체의 동작은 유지하며 호출 여부만 확인해야 하는가? → vi.spyOn 사용 - 특정 함수만 Mocking하고 나머지는 실제 로직을 태워야 하는가? → importOriginal() 기반 Partial Mock 사용 - 테스트 간 간섭이 발생하는가? → afterEach 내 mockRestore() 호출 여부 확인 - TS 컴파일 에러가 발생하는가? → vi.mocked()로 타입 캐스팅 수행

태그

#Vitest #Unit Testing #Dependency Isolation #Mocking #TypeScript

원문 읽기