# [[Unit Testing]]

## 📌 Brief Summary
Unit testing(단위 테스트)은 프론트엔드 시스템에서 컴포넌트나 커스텀 훅과 같은 개별 로직을 독립적으로 검증하는 과정입니다 [1]. 특히 기존 코드베이스를 리팩토링할 때 기능이 손상되지 않았는지 보장하는 필수적인 방어 수단으로 활용됩니다 [2, 3]. 확장 가능(Scalable)한 폴더 구조에서는 유지보수성을 높이기 위해 단위 테스트 파일을 대상 컴포넌트와 동일한 위치에 두는 것이 권장됩니다 [4, 5].

## 📖 Core Content
- **리팩토링의 필수 선행 조건**: 낯선 React 코드베이스나 레거시 코드를 리팩토링할 때(예: TypeScript 변환, 함수형 컴포넌트 및 훅(Hooks) 도입 등) **가장 먼저 단위 테스트를 작성하는 것이 강력히 권장**됩니다 [2, 3, 6]. 테스트를 작성하는 과정 자체가 앱의 동작 방식을 이해하는 데 도움을 주며, 코드를 개선하는 과정에서 기능이 깨지는 것을 즉각적으로 알려주는 역할을 합니다 [2, 7].
- **폴더 구조 및 파일 배치 (Colocation)**: 단위 테스트 파일은 관련된 컴포넌트 파일명과 동일하게 작성(예: `Button.test.tsx` [8])하여 개발자가 쉽게 식별할 수 있도록 해야 합니다 [9]. 통합 테스트의 경우 별도의 폴더에 관리할 수 있지만, **단위 테스트는 유지보수성을 극대화하기 위해 테스트 대상 컴포넌트나 기능(feature)과 최대한 가까운 동일한 폴더 내에 배치(colocate)**하는 것이 모범 사례입니다 [4, 5].
- **관심사 분리와 테스트 용이성**: 크고 복잡한 컴포넌트 내부의 데이터 패칭이나 폼 핸들링 등의 비즈니스 로직을 **커스텀 훅(Custom Hooks)으로 분리하면, UI 로직과 비즈니스 로직이 격리되어 느린 통합 테스트 대신 빠르고 독립적인 단위 테스트를 수행**하기가 훨씬 수월해집니다 [1].
- **팀 워크플로우 및 통합 (CI/CD)**: 소규모 팀이든 대규모 팀이든 안정적인 Git 워크플로우를 위해, 코드를 메인(Main) 브랜치에 병합(merge)하기 전에는 **반드시 모든 단위 테스트와 CI 체크가 통과**되도록 보장해야 합니다 [10, 11].
- **사용되는 주요 도구**: React와 Vite를 사용하는 최신 프론트엔드 환경에서는 견고한 단위 테스트를 위해 **Vitest 또는 Jest**가 활용되며 [4], UI 컴포넌트 테스트에는 **testing-library**를 사용하는 방식이 언급됩니다 [7].

## 🔗 Knowledge Connections
- **Related Topics:** [[Refactoring Techniques]], [[Folder Structure]], [[Custom Hooks]], [[Clean Code Principles]]
- **Projects/Contexts:** [[Scalable React Architecture]], [[Git Workflow for Frontend Teams]]
- **Contradictions/Notes:** 전반적으로 모든 코드에 테스트를 작성하는 것이 권장되지만, 작은 규모의 앱이거나 일회성 프로젝트의 경우에는 굳이 테스트 작성에 큰 노력을 들일 필요가 없을 수도 있다는 일부 의견이 존재합니다 [12].

---
*Last updated: 2026-04-26*