아키텍처
테스트 코드를 왜 그리고 어떻게 작성해야 할까?
두줄요약
테스트는 디버깅 비용과 회귀 버그 위험을 줄이고 실행 가능한 문서 역할을 합니다. Jest 예제로 독립성, 결과 검증, 가독성, 비즈니스 명세 중심의 작성법을 설명했습니다.
선택 이유
- 테스트 범위 분리를 통한 결함 위치와 발생 케이스의 빠른 파악
- 회귀 테스트 기반 변경·리팩터링 불안 완화와 디버깅 비용 절감
- 코드와 가까운 실행 가능한 문서로서의 테스트 명세
구조와 흐름
- unit·integration·e2e 테스트의 역할별 검증 범위 구성
- CI 단계의 자동화 테스트를 통한 버그 배포 방지
- Arrange-Act-Assert 또는 Given-When-Then 기반 준비·실행·검증 구분
주의할 점
- beforeEach 공유 상태와 과도한 중복 제거로 인한 테스트 간 결합
- mock·spy 기반 내부 구현과 호출 횟수 검증에 따른 리팩터링 취약성
- 구현 용어 중심의 모호한 테스트명과 본문 밖 정보 의존
적용해볼 점
- DRY보다 DAMP를 우선한 독립적·서술적 테스트와 fixture 활용
- 내부 메서드 호출 대신 상태 변화·예외 등 실행 결과 검증
- 비즈니스 행위를 담은 테스트명과 읽기 쉬운 테스트 본문 작성
