개발공부/테스트코드
테스트 코드
hani:)
2025. 5. 13. 19:52
결론부터 말하자면, 저는 현재 프로젝트에 Jest부터 도입할 예정입니다.
이유는 먼저 간단한 유틸 함수와 컴포넌트 테스트부터 시작해 점차 복잡한 UI와 사용자 플로우, 그리고 Vitest, Cypress 등 최신 도구까지 확장해나갈 계획입니다.
목차
테스트 코드의 필요성
테스트 코드는 단순히 "잘 돌아가는지 확인"하는 것 이상의 의미를 가진다.
- 코드 품질 보장: 버그를 미리 발견하고, 코드가 의도대로 동작하는지 검증
- 유지보수 용이성: 코드 변경 시 기존 기능이 깨지지 않았는지 빠르게 확인
- 자동화와 빠른 피드백: 반복적인 검증을 자동화해 실수 감소
- 협업과 문서화: 테스트 케이스는 코드의 의도와 사용법을 명확하게 해줘 팀원과의 협업에 큰 도움
테스트의 종류와 도구
테스트 종류 | 설명 | 대표 도구 |
유닛 테스트 | 함수, 컴포넌트 등 작은 단위가 올바르게 동작하는지 검증 | Jest, React Testing Library |
통합 테스트 | 여러 컴포넌트/모듈이 함께 동작하는지 검증 | Jest, React Testing Library |
E2E(종단간) 테스트 | 실제 사용자처럼 앱 전체 흐름을 시뮬레이션하며 검증 | Cypress, Playwright |
시각적 테스트 | UI가 의도대로 보이는지 확인 | Storybook |
접근성/브라우저 테스트 | 다양한 환경에서 정상 동작/접근성 보장 확인 | Storybook Addons 등 |
프론트엔드 단위 테스트 주요 도구와 방식
1. Jest + React Testing Library
- 설명: React 애플리케이션에서 표준처럼 사용되는 조합
- Jest는 테스트 러너 및 환경을 제공하고, React Testing Library(RTL)는 실제 사용자의 시각에서 컴포넌트를 테스트하게 도와줌
- 대상: 개별 React 컴포넌트, 유틸리티 함수
- 장점
- React 컴포넌트 테스트에 최적화
- DOM 기반 테스트로 사용자 관점의 검증 가능
- 간결한 API와 풍부한 커뮤니티 지원
- 빠른 실행 속도(밀리초 단위)
- props/state 변화에 따른 UI 반응 테스트 용이
- 단점
- 초기 설정이 다소 복잡할 수 있음
- 복잡한 사용자 상호작용 시뮬레이션에는 한계
- OpenLayers 등 복잡한 라이브러리 사용 시 모킹 필요
2. Cypress Component Testing
- 설명: 실제 브라우저 환경에서 컴포넌트를 렌더링하고 동작을 검증하는 방식
- 장점
- 실제 브라우저에서 테스트해 정확성 높음
- 시각적 디버깅이 용이
- 지도 렌더링 등 복잡한 UI 테스트에 적합
- 단점
- Jest보다 실행 속도가 느림
- 설정이 상대적으로 복잡함
3. Storybook + Loki/Chromatic (시각적 테스트)
- 설명: Storybook에서 컴포넌트의 UI를 캡처하고, 이전 스냅샷과 비교해 시각적 변화(레이아웃, 색상, 폰트 등)를 자동으로 검증
- 대상: CSS/레이아웃, 지도 레이어 스타일링, 시설물 표시 방식 등
- 장점
- UI 변경 감지에 탁월
- 캔버스 기반 지도 요소의 시각적 검증 가능
- 단점
- 환경 구성 복잡
- false positive(의도치 않은 경고) 발생 가능
4. Storybook + Interactions
- 설명: Storybook에서 컴포넌트 문서화와 동작 테스트를 동시에 진행 가능
- 장점
- 문서화와 테스트를 한 번에
- 다양한 상태와 동작 시나리오 테스트에 유용
- 단점
- 순수 테스트 도구보다 설정이 복잡
- 학습 곡선 존재
5. Vitest
- 설명: Vite 기반의 초고속 테스트 러너로, Jest와 유사한 API를 제공
- 장점
- 실행 속도가 매우 빠름
- HMR(Hot Module Replacement) 지원
- Jest와 호환되는 API
- 단점
- 비교적 최신 도구라 레퍼런스가 적음
728x90