통합 테스트 (Integration Testing)
쉽게 풀면
자동차를 만들 때 엔진, 바퀴, 브레이크를 각각 따로 시험해서 잘 작동한다고 확인했다고 해도, 이걸 하나로 조립했을 때 문제없이 굴러간다는 보장은 없습니다. 엔진의 출력과 바퀴의 크기가 안 맞을 수도 있고, 브레이크 신호가 엔진 제어 장치와 충돌할 수도 있습니다. 소프트웨어도 마찬가지입니다. 각 기능을 담당하는 모듈 하나하나는 단위 테스트로 검증했더라도, 로그인 모듈과 결제 모듈을 연결했을 때 데이터가 올바르게 주고받아지는지는 별도로 확인해야 합니다. 이렇게 여러 모듈이 "합쳐졌을 때"의 동작을 검증하는 과정이 통합 테스트입니다.
왜 중요한가
소프트웨어시스템이 마이크로서비스나 다양한 외부 API로 구성되는 경우가 많아지면서, 개별 모듈의 정확성만으로는 전체 시스템의 신뢰성을 보장할 수 없게 되었습니다. 통합 테스트는 모듈 간 인터페이스 불일치, 데이터 형식 오류, 네트워크 지연 등 단위 테스트로는 잡아내기 어려운 문제를 발견하는 단계로서, 소프트웨어공학 논문에서 시스템 검증 방법론을 설명할 때 핵심적으로 다뤄집니다.
논문에서는 이렇게 쓰입니다
이 문장은 먼저 함수 하나하나가 올바르게 동작하는지 확인한 다음, 여러 구성 요소를 실제로 연결한 상태에서 데이터가 잘 오가는지까지 검증했다는 뜻입니다.
분산시스템 연구에서는 여러 서비스가 네트워크를 통해 상호작용할 때 발생할 수 있는 장애와 예외 상황까지 포함해 통합 테스트를 설계하는 경우가 흔합니다.
조금 더 깊게 보면
통합 테스트는 접근 방식에 따라 하위 모듈부터 점진적으로 결합해나가는 상향식(bottom-up), 상위 모듈부터 시작해 하위 모듈을 임시 대역(스텁)으로 대체해가는 하향식(top-down), 전체를 한 번에 결합하는 빅뱅 방식 등으로 나뉩니다. 실제 모듈이 아직 준비되지 않은 부분은 스텁이나 목(mock) 객체로 대체해 테스트를 진행하기도 하며, 이런 전략 선택이 오류 발견 시점과 디버깅 난이도에 영향을 미칩니다.
주의할 점
통합 테스트는 단위 테스트보다 범위가 넓어서 오류가 발생했을 때 정확히 어느 모듈이 원인인지 찾기가 더 어렵습니다. 그래서 보통 단위 테스트로 개별 부품의 정확성을 먼저 확인한 뒤, 그 위에 통합 테스트를 쌓는 방식으로 진행하며, 테스트 커버리지만 높다고 해서 통합 시 발생하는 문제까지 전부 걸러진다고 착각해서는 안 됩니다.