8장 - 통합 테스트를 하는 이유

8장에서 다루는 내용

• 통합 테스트의 역할 이해
• 테스트 피라미드의 개념 자세히 살펴보기
• 가치 있는 통합 테스트 작성

 

단위 테스트에만 전적으로 의존하면 시스템이 전체적으로 잘 동작하는지 확신할 수 없습니다.

각 부분이 데이터베이스나 메시지 버스 등의 외부 시스템과 어떻게 통합되는지 확인해야 합니다.

 

예를 들어 다음과 같은 경우가 있을 수 있습니다.

• 단위 테스트는 통과했지만 Spring Bean Wiring이 되지 않아 애플리케이션이 실행되지 않을 수 있습니다.

통합 테스트란?

간단하게 단위 테스트가 아닌 모든 테스트는 통합 테스트이다.

 

통합 테스트가 어려운 이유 2가지

• 관련된 협력자가 많아 테스트가 비대해짐
• 프로세스 외부 의존성 운영이 필요

빠른 피드백, 유지 보수성을 포기하는 대신 회귀 방지와 리팩토링 내성이 높습니다.

 

통합 테스트에서도 빠른 실패를 하자

예기치 않은 오류가 발생하자마자 예외를 던져 현재 연산을 중단하면 좋다.

• 개발 환경에 발견된 버그는 운영 환경보다 고치기 훨씬 쉽다.
• 버그는 애플리케이션의 상태를 손상되고 이것이 데이터베이스로 침투하면 고치기가 어려워진다.

 

어떤 프로세스 외부 의존성을 직접 테스트할까?

관리 의존성 (데이터베이스) - 외부시스템은 API를 통해 데이터베이스에 접근 - 전체 제어 가능

비관리 의존성(SMTP 서버와 메시지 버스) - 다른 애플리케이션에서 볼 수 있는 부작용을 발생시킴 - 전체 제어 불가능

 

관리 의존성은 실제 인스턴스를 사용하고, 비관리 의존성은 목으로 대체한다.

관리 의존성은 구현 세부 사항이며, 비관리 의존성은 시스템의 식별할 수 있는 동작이다.

 

하지만 다른 애플리케이션에서 접근할 수 있는 데이터베이스는 관리 의존성이면서 비관리 의존성이다!!

이런 경우에는 데이터베이스에서 관리 부분, 비관리 부분을 잘 구분하여 비관리 부분은 목으로 대체해야 한다.

 

E2E와 통합 테스트의 차이는?

E2E 테스트는 어떤 외부 프로세스 의존성도 목으로 대체하지 않습니다.

반면 통합 테스트는 비관리 의존성을 목으로 대체합니다.

 

인터페이스와 느슨한 결합

보통 인터페이스에 구현이 하나만 있더라도 데이터베이스나 메시지 버스와 같은 외부 의존성을 위해 인터페이스를 사용합니다.

대게 OCP를 지키거나, 외부 의존성을 추상화하여 느슨한 결합을 위해 사용합니다.

하지만 단일 구현을 위한 인터페이스는 추상화가 아니며, OCP를 지키고자 했을 때는 YAGNI를 위반합니다.

YAGNI는 현재 필요하지 않은 기능에 시간을 들이지 말라는 것입니다.

 

아래 링크는 저자가 쓴 글입니다. 

https://enterprisecraftsmanship.com/posts/ocp-vs-yagni

OCP vs YAGNI

 

그러면 인터페이스를 쓰는 이유는?

Mock을 위해서이다.

인터페이스가 없으면 테스트 대역을 만들 수 없기 때문이다.

 

통합 테스트 모범 사례

• 도메인 모델 경계 명시하기
• 애플리케이션 내 계층 줄이기
• 순환 의존성 제거하기

 

로깅 기능을 테스트하는 방법

로깅은 AOP와 같은 횡단 기능으로 코드베이스 어느 부분에서나 필요로 할 수 있다.

이 기능을 테스트해야 할까?

로깅은 애플리케이션의 식별할 수 있는 동작인가? 구현 세부사항인가?

로깅은 부작용을 초래하고 개발자 이외에 다른 사람이 보는 경우라면 테스트가 필요합니다.

하지만 개발자만 본다면 구현 세부사항이므로 테스트하면 안 됩니다.

개인적으로는 로깅을 굳이 테스트해야 할까?라는 생각이 듭니다.

 

로깅은 얼마나 많으면 충분한가?

최대한 과도하게 사용하지 않는 것이 중요하다.

과도한 로깅은 코드를 혼란스럽게 하며, 로그가 많을수록 관련 정보를 찾기가 어려워진다.

따라서 최소한으로 유지하는 게 좋으며, 도메인 모델에서는 로깅을 절대 사용하지 않는 것이 좋습니다.