[단위 테스트] 통합 테스트 (narrow integeration, wide integeration)

들어가기전 용어 정리

SUT : 테스트 대상 시스템 (System Under Test)
테스트 대상 자체를 뜻하며, 작은 코드 조각(단위) 을 말함.
여기서, 작은 코드 조각(단위) 란 단일 클래스가 될 수도 있고, 단일 클래스 또는 단일 클래스와 의존하는 클래스들로 이루어질 수 있다.
작은 코드 조각(단위)를 보는 관점에 따라서 달라진다.

---

통합 테스트

독립적으로 개발된 소프트웨어 단위들이 서로 연결됐을 때 제대로 동작하는지를 테스트 하는 것

 

좁은 범위의 통합 테스트 (narrow integeration test)

• 별도의 서비스와 통신하는 나의 서비스의 코드 부분만을 실행
• 별도의 서비스를 테스트 더블로 대체
• 대개 단위 테스트보다 큰 범위를 가지지 않으며, 보통 단위 테스트에 사용되는 같은 테스트 프레임워크로 실행

위 내용을 좀 더 쉽게 풀어 써보자면

스프링부트를 통한 @SpringBootTest 는 애플리케이션 컨텍스트를 로드합니다.  스프링 Bean을 모두 로드한다.

테스트에 필요한 bean들이 다 로드되기때문에, 손쉽게 테스트를 진행 할 수 있다.

 

좁은 범위의 통합 테스트를 한다면, sut(테스트 하는 대상) 을 제외한 나머지들을 테스트 더블로 대체하게 된다.

@SpringBootTest를 통해 Bean을 로드하지 않고 sut가 의존하는 객체들만 생성해 테스트를 하게 된다.

 

여기서, 두번째 케이스가 좁은 범위의 통합 테스트에 가깝다.

좁은 범위의 통합 테스트를 할 경우, 범위가 제한적이기 떄문에 매우 빠르게 실행되고, 빠른 피드백을 받을 수 있다.

 

광범위한 통합 테스트(broad integration test)

• 모든 서비스의 실제 버전이 필요하며, 상당한 테스트 환경 및 네트워크 접근을 요구
• 상호작용을 담당하는 코드뿐만 아니라 모든 서비스를 통한 코드 경로를 실행

광범위한 통합 테스트는 위의 @SpringBootTest를 사용해 테스트를 진행한 경우이다.

 

첫번째 그림 : wide integration test, 두번째 그림 : narrow integration test

---

개인적 의견

필자는 위의 narrow Integration test 로 리팩토링을 통해, 테스트 빌드 시간을 개선한 적이 있다.

확실히 테스트 빌드 시간이 줄어들어서 프로덕션 코드를 수정하고 빠르게 회귀 테스트를 할 수 있었다.

narrow Integeration test 는 확실히 빌드 시간이 단축이 되지만, 그만큼 대체 해야하는 테스트 더블을 만들어야 한다.

mock 프레임워크를 이용해 테스트 더블을 만들 수도 있지만, 그렇게 된다면 테스트 코드내에 프로덕션 코드의 구현코드도 알게된다. 

 

필자의 프로젝트에서는 Repository를 stub 객체로 만들어 인메모리 환경에서 저장소를 사용해서 해결했는데, 이 부분에도 단점이 극명하게 보였다.

 

성능은 확실히 개선됐지만, 단점에 대해서 극복방법은 아직 찾지 못했다.

극복 방법을 찾기 위해서 테스트에 대해 공부하고 포스팅하고 있다.

나중에 찾게되면 다시 포스팅 하겠다.

 

이 링크는 프로젝트에서 개선한 내용을 작성한 글이다.

 

 

 

참고

https://martinfowler.com/bliki/IntegrationTest.html

단위 테스트 (블라디미르 코리코프 지음)

https://techblog.woowahan.com/14874/