테스트 코드 작성 전략
pxd XE그룹이 사내 회의실 예약 시스템 the-zero(The0)의 백엔드를 개발하며 정리한 테스트 코드 경험은, 테스트를 작성하는 이유를 크게 두 가지로 압축한다. 하나는 애플리케이션의 신뢰성 확보이고, 다른 하나는 이 코드를 나중에 다시 보게 될 미래의 동료와 미래의 자신을 위한 배려다. 테스트 없이 기존 기능과 새 기능이 뒤엉키며 코드가 점점 엉망이 되는 악순환은 실무에서 자주 겪는 문제이며, 테스트 코드는 리팩터링과 기능 추가에 대한 최소한의 안전장치로 작동해 이 악순환을 끊는다.
테스트 코드를 작성하는 과정 자체가 설계에도 영향을 준다. 유닛 테스트가 가능하려면 함수가 하나의 기능만 하도록 잘게 쪼개져야 하는데, 이 요구는 자연스럽게 다른 사람이 이해하기 쉬운 코드로 이어진다. Kent C. Dodds의 글을 인용해 정적 분석·유닛 테스트·통합 테스트·E2E 테스트로 쌓이는 테스트 피라미드 개념을 설명하는데, 위 단계로 갈수록 신뢰도는 높아지지만 비용과 시간도 함께 커지는 트레이드오프가 있다. E2E 테스트(Cypress)는 실제 구동 환경까지 검증해 신뢰도가 가장 높지만 작성 시간이 오래 걸리고 화면이 자주 바뀌면 셀렉터도 함께 수정해야 하는 유지보수 부담이 크다. 반대로 유닛/통합 테스트(Jest)는 빠르고 저렴하지만, 그렇다고 유닛 테스트만으로 전부를 대체하는 것은 바람직하지 않으며, 소프트웨어를 사용하는 방식과 유사한 테스트일수록 더 큰 신뢰를 준다는 원칙에 따라 여러 테스트 유형을 복합적으로 구성해야 한다.
테스트 코드 도입의 실질적 효과로는 함수를 잘게 나누며 얻는 사고의 확장, 사이드 이펙트 없이 버그를 빠르게 발견·수정하는 능력, 애플리케이션에 대한 신뢰를 바탕으로 리팩터링과 새로운 아이디어를 과감히 시도할 수 있는 여지가 꼽힌다. 완벽한 테스트 커버리지는 불가능하지만, 자신의 테스트 능력을 과신하지 않고 최소한의 안전장치를 마련하는 태도 자체가 실무에서 반복적으로 발견되는 버그를 줄이는 데 도움이 된다.
핵심 내용
- 테스트 코드를 쓰는 두 가지 이유: 애플리케이션 신뢰성 확보, 미래의 동료/자신을 위한 가독성 확보
- 유닛 테스트를 위해 함수를 잘게 쪼개는 과정 자체가 이해하기 쉬운 코드 설계로 이어짐
- 테스트 피라미드(정적 분석-유닛-통합-E2E): 위로 갈수록 신뢰도는 높지만 비용·시간이 커지는 트레이드오프
- E2E(Cypress)는 신뢰도가 높지만 작성 시간이 길고 UI 변경 시 셀렉터 유지보수 부담이 큼
- 유닛 테스트만으로는 부족 — 소프트웨어의 실제 사용 방식과 유사한 테스트일수록 더 큰 신뢰를 준다는 원칙에 따라 복합적으로 구성
- 효과: 사고의 확장, 사이드 이펙트 없는 빠른 버그 수정, 리팩터링에 대한 자신감 확보
관련 개념
- FED-프론트엔드-UX-워크플로우 — the-zero(The0) 프로젝트의 UX 프로세스 전반을 다루는 자매 사례
- SOLID-원칙과-프론트엔드 — 함수·컴포넌트를 작은 책임 단위로 나누는 설계 원칙이 테스트 용이성과 맞닿는 지점
출처
- the-zero 테스트 코드를 작성하며 — 2024-04-15, 알 수 없는 사용자