통합 테스트 (Integration Testing)

통합 테스트(Integration Testing)는 둘 이상의 소프트웨어 구성 요소를 함께 실행해 서로 데이터를 주고받으며 기대한 결과를 만드는지 확인하는 테스트입니다. 함수 내부 계산보다 연결 지점의 형식과 처리 흐름에 초점을 둡니다. API 처리 코드와 데이터 저장 코드를 묶어 검사하는 경우가 한 예입니다.

구성 요소 사이의 연결 지점

서버가 요청을 받아 주문을 저장하려면 요청 해석, 입력 검증, 저장 처리, 응답 생성이 이어져야 합니다. 각 부분을 따로 검사했어도 필드 이름이나 값의 형식이 어긋나면 연결 단계에서 실패합니다. 마이크로소프트의 통합 테스트 문서는 둘 이상의 구성 요소가 함께 기대 결과를 만드는지 확인하는 검사로 설명합니다. 검사 범위에 요청 처리에 필요한 구성 요소 전체가 들어가는 경우도 있습니다.

주문 생성 요청을 보낸 뒤 성공 상태만 확인하면 저장된 값의 오류를 놓칠 수 있습니다. 입력한 수량이 데이터베이스 레코드에 같은 값으로 남았는지, 생성된 주문 번호가 응답과 일치하는지까지 확인하면 요청과 저장 사이의 연결을 검사합니다. 이 예시에서 검증하는 것은 주문 생성 경로이며, 취소나 환불 경로의 동작은 별도 사례로 남습니다.

오류 경로도 연결의 일부입니다. 저장 단계가 실패했을 때 성공 응답이 나가는지, 잘못된 입력이 저장 계층까지 도달하는지에 따라 사용자에게 보이는 결과가 달라집니다. 테스트를 읽는 사람이 어느 구성 요소를 실제로 실행하고 어떤 의존성을 대신했는지 알 수 있어야 실패 지점과 검증 범위를 함께 해석할 수 있습니다.

실제 자원과 대체 구현의 차이

데이터베이스를 메모리 안의 대체 구현으로 바꾸면 준비가 간단해지는 경우가 있습니다. 다만 저장 엔진이 달라지면 같은 질의도 다른 결과를 낼 수 있습니다. 마이크로소프트의 EF Core 테스트 전략은 데이터베이스 대체 구현에서 통과한 결과가 실제 자원의 동작까지 보장하지 않는다고 설명합니다. 문자 비교 방식이나 지원하는 질의 차이가 그 원인입니다.

운영에서 쓰는 것과 같은 종류의 데이터베이스를 테스트용으로 준비하면 그 엔진의 동작을 포함해 검사할 수 있습니다. 운영 중인 고객 데이터베이스에 테스트 주문을 쓰라는 의미는 아닙니다. 테스트용 데이터와 접근 권한을 분리하고, 데이터베이스 테이블의 구조와 관련 설정을 기록하면 어느 환경에서 결과를 얻었는지 남길 수 있습니다.

실제 자원을 쓴다는 이유만으로 모든 통합 테스트가 느리다고 단정할 수는 없습니다. 같은 EF Core 문서는 로컬 데이터베이스와 적절한 데이터량을 쓰는 시험의 실행 비용을 따로 살펴보도록 설명합니다. 반면 외부 서비스 호출에는 연결 지연과 서비스 제한이 더해집니다. 비용은 검사 이름보다 실제 실행 자원과 데이터 준비 방식의 영향을 받습니다.

검사 범위와 반복 실행 조건

단위 테스트는 작은 구성 요소의 동작에 초점을 두고, 통합 테스트는 여러 구성 요소가 맞물리는 지점을 다룹니다. 브라우저에서 시작해 저장 결과까지 확인하는 종단 간 테스트도 여러 구성 요소를 통과하므로 범위가 겹칩니다. 팀에서 같은 검사를 다르게 부를 때는 시작점, 끝점, 포함한 외부 자원을 기준으로 맞추면 이름만으로 생기는 혼동을 줄일 수 있습니다.

앞선 테스트가 남긴 데이터 때문에 다음 테스트가 통과하면 검사 순서에 따라 결과가 달라집니다. EF Core의 테스트 전략 문서는 여러 테스트가 같은 데이터를 바꿀 때 서로 방해하는 문제를 지적합니다. 테스트마다 별도 데이터를 만들거나 실행 뒤 상태를 복원하는 방식으로 의도한 초기 조건을 유지합니다. 동시에 실행할 때 데이터가 겹치는지도 확인 대상입니다.

빌드에서 통합 테스트가 실패하면 응답 내용과 저장 결과, 실행한 설정을 함께 살펴봅니다. 테스트 서버가 시작되지 않은 실패와 시작된 서버가 잘못된 결과를 낸 실패는 조사 지점이 다릅니다. 디버깅에 필요한 요청·응답 기록을 남기되 인증 정보와 실제 이용자의 데이터를 넣지 않으면 같은 연결 문제를 안전하게 다시 재현할 수 있습니다.