단위 테스트

단위 테스트란 무엇인가

단위 테스트(Unit Test)는 함수·메서드·모듈처럼 더 이상 쪼갤 수 없는 가장 작은 코드 단위가 의도대로 동작하는지 검증하는 테스트다. 소프트웨어 품질 활동(QA)의 출발점에 해당하며, 결함을 가능한 한 빨리, 작은 범위에서 잡아내는 데 목적이 있다.

입력에 대해 기대한 출력이 나오는지, 경계값과 예외 상황에서 어떻게 반응하는지를 좁은 시야로 확인한다. 검증 범위가 작은 만큼 실패가 발생했을 때 원인을 특정하기 쉽다는 것이 가장 큰 강점이다.

왜 가장 먼저 수행하는가

결함은 발견 시점이 늦어질수록 수정 비용이 가파르게 커진다. 설계 단계에서 잡을 수 있던 문제를 운영 단계에서 발견하면 영향 범위와 회귀 위험이 함께 늘어나기 때문이다.

단위 테스트는 개발자가 코드를 작성하는 시점에 결함을 즉시 차단해, 통합·시스템 단계로 결함이 전이되는 것을 막는다. 품질을 마지막에 검사로 걸러내는 것이 아니라 만들어 넣는다는 관점이 단위 테스트의 본질이며, 이 지점에서 QC(검사 중심)와 QA(예방 중심)의 차이가 드러난다.

독립성과 빠른 피드백

좋은 단위 테스트는 외부 의존성에서 분리되어 단독으로 실행될 수 있어야 한다. 데이터베이스·네트워크·파일 시스템 같은 외부 자원에 직접 의존하면 테스트가 느려지고 환경에 따라 결과가 흔들린다.

이를 차단하기 위해 가짜 객체로 의존성을 대체하는 Mock·Stub 기법을 활용해 검증 대상만 고립시킨다. 독립적으로 구성된 테스트는 수초 안에 반복 실행할 수 있어, 코드를 고칠 때마다 즉각적인 피드백을 제공하는 안전망이 된다.

테스트 주도 개발과의 관계

단위 테스트는 테스트 주도 개발(TDD)의 기반 도구다. TDD는 실패하는 테스트를 먼저 작성하고, 그 테스트를 통과시키는 최소한의 구현을 더한 뒤 구조를 다듬는 순서로 진행된다.

테스트가 명세 역할을 하므로 코드가 무엇을 해야 하는지 먼저 합의되고, 구현은 그 합의를 만족시키는 방향으로 수렴한다. 다만 TDD가 아니더라도 단위 테스트 자체의 가치는 독립적으로 성립하며, 기존 코드에 사후적으로 테스트를 보강하는 방식도 충분히 유효하다.

커버리지의 함정

단위 테스트의 성과를 코드 커버리지 수치 하나로 환산하려는 시도는 흔한 오해다. 커버리지는 어떤 코드가 한 번이라도 실행되었는지를 보여줄 뿐, 그 코드가 올바른지를 보장하지 않는다.

단언(assertion) 없이 호출만 하는 테스트도 커버리지를 끌어올리기 때문이다. 수치를 목표로 삼으면 의미 없는 테스트가 양산되어 유지보수 부담만 커진다.

핵심 로직과 경계 조건, 예외 경로에 검증을 집중하는 편이 막연히 전 구간을 덮는 것보다 결함 예방에 효과적이다.

회귀 방지와 리팩터링의 토대

축적된 단위 테스트는 코드를 안심하고 변경할 수 있게 해 주는 회귀 방지 장치다. 새 기능을 추가하거나 내부 구조를 개선할 때, 기존 동작이 깨지지 않았는지를 테스트 묶음이 자동으로 검증한다.

이 안전망이 없으면 개발자는 변경을 두려워하고, 코드는 손대기 어려운 상태로 굳어진다. 반대로 신뢰할 수 있는 단위 테스트가 갖춰진 코드베이스는 리팩터링과 기능 확장을 반복하면서도 품질을 유지한다.

단위 테스트는 결국 변화에 견디는 소프트웨어를 만드는 가장 기초적인 투자다.