통합 테스트

통합 테스트란 무엇인가

통합 테스트(Integration Test)는 개별적으로 검증을 마친 모듈들을 결합했을 때, 그 사이의 인터페이스가 올바르게 동작하는지를 확인하는 테스트다. 단위 테스트가 부품 하나하나의 정상 작동을 보장한다면, 통합 테스트는 부품을 이어 붙인 연결부에서 데이터와 제어가 제대로 오가는지를 검증한다.

검증의 초점은 모듈 내부 로직이 아니라 모듈과 모듈 사이의 경계, 즉 호출 규약·데이터 형식·예외 전파에 놓인다. 각 부품이 멀쩡해도 조립 지점에서 결함이 드러나는 경우가 많기 때문에 반드시 필요한 단계다.

개별 정상이 전체 정상은 아니다

단위 테스트를 모두 통과한 모듈을 모았다고 해서 시스템이 정상 작동하리라는 보장은 없다. 한 모듈이 넘기는 데이터 형식과 다른 모듈이 기대하는 형식이 미묘하게 어긋나거나, 호출 순서·트랜잭션 경계·시간 의존성에서 충돌이 생기기 때문이다.

이런 결함은 모듈을 따로 볼 때는 보이지 않고 결합한 순간에만 나타난다. 통합 테스트는 바로 이 사각지대를 겨냥해, 약속한 인터페이스가 실제 결합 상황에서 지켜지는지를 드러낸다.

통합 전략 · 결합의 순서

모듈을 결합해 가는 순서에 따라 전략이 갈린다. 상위 모듈부터 결합하며 내려가는 하향식은 전체 흐름을 일찍 확인할 수 있으나 아직 없는 하위 모듈을 임시 대역인 Stub으로 채워야 한다.

하위 모듈부터 쌓아 올리는 상향식은 기반 기능을 먼저 다지지만 상위 호출을 흉내 내는 Driver가 필요하다. 모든 모듈을 한꺼번에 붙이는 빅뱅 방식은 준비가 단순하나, 결함이 터졌을 때 원인 구간을 좁히기 어렵다.

어느 전략이든 결합 지점을 통제 가능한 크기로 관리하는 것이 핵심이다.

Mock과 테스트 대역의 역할

통합 테스트에서는 아직 완성되지 않았거나 통제하기 어려운 외부 구성요소를 가짜 객체로 대체하는 일이 잦다. 결제 게이트웨이·외부 API·메시지 큐처럼 직접 호출하기 부담스러운 대상을 Mock으로 모사하면, 검증하려는 연결부에만 집중할 수 있다.

다만 대역을 지나치게 많이 쓰면 실제 통합이 아니라 가정만 검증하는 결과가 되므로 균형이 필요하다. 핵심 연동 경로는 가능한 한 실제에 가까운 환경에서 확인하고, 통제가 불가능한 외부 경계에만 대역을 적용하는 것이 합리적이다.

인터페이스 명세가 곧 품질

통합 테스트의 성패는 모듈 간 인터페이스가 얼마나 명확하게 합의되어 있는가에 달려 있다. 입력·출력의 형식, 오류 코드, 호출 전제 조건이 문서로 정리되어 있지 않으면, 테스트는 무엇을 기대값으로 삼아야 할지 정의할 수 없다.

명세가 모호한 채로 결합을 진행하면 양쪽 모듈이 서로 다른 가정을 품게 되고, 통합 시점에 충돌이 한꺼번에 쏟아진다. 따라서 통합 테스트는 단순한 검증 활동을 넘어, 인터페이스 계약이 실제로 지켜지는지를 확인하는 절차로 보는 편이 정확하다.

단위와 시스템 사이의 다리

통합 테스트는 단위 테스트와 시스템 테스트를 잇는 중간 다리에 위치한다. 단위 테스트가 부품의 정확성을, 시스템 테스트가 요구사항 전체의 충족을 본다면, 통합 테스트는 그 사이에서 결합 구조의 건전성을 확보한다.

이 단계가 부실하면 시스템 테스트에서 발견되는 결함의 원인이 어느 연결부에 있는지 추적하기 어려워지고, 전체 검증 일정이 흔들린다. 결합을 점진적으로, 추적 가능한 단위로 통합해 두어야 이후 단계의 결함 분석 비용이 줄어든다.