8.1 통합 테스트는 무엇인가?
단위 테스트가 아닌 모든 테스트가 통합 테스트에 해당된다. 단위 테스트는 도메인 모델을 다루는 반면, 통합 테스트는 프로세스 외부 의존성과 도메인 모델을 연결하는 코드를 확인한다. 단위 테스트로 가능한 한 많이 비즈니스 시나리오 예외 상황을 확인하고, 통합 테스트는 주요 흐름과 단위 테스트가 다루지 못하는 기타 예외 상황을 다룬다.
8.2 어떤 프로세스 외부 의존성을 직접 테스트해야 하는가?
8.2.1 프로세스 외부 의존성의 두 가지 유형
- 관리의존성(전체를 제어할 수 있는 프로세스 외부 의존성): 애플리케이션을 통해서만 접근할 수 있으며 대표적인 예로 데이터베이스가 있다.
- 비관리 의존성(전체를 제어할 수 없는 프로세스 외부 의존성): 대표적인 예는 SMTP서버와 메시지 버스 등이 있다.
관리 의존성은 실제 인스턴스를 사용하고, 비관리 의존성은 목으로 대체하라
8.2.2 관리 의존성이면서 비관리 의존성인 프로세스 외부 의존서어 다루기
- 다른 애플리케이션에서 볼 수 있는 테이블은 비관리 의존성으로 취급하라.
8.2.3 통합 테스트에서 실제 데이터베이스를 사용할 수 없으면 어떻게 할까?
- 데이터베이스를 그대로 테스트할 수 없으면 통합 테스트를 아예 작성하지 말고 도메인 모델의 단위 테스트에만 집중하라.
8.3 통합테스트
- 읽기는 컨트롤러에서 내부적으로 사용하는 동일한 코드를 써서 구현해야 한다.
8.4 의존성 추상화를 위한 인터페이스 사용
- 인터페이스가 진정으로 추상화 되려면 구현이 적어도 두 가지는 있어야 한다. 구현체가 하나인데 굳이 인터페이스로 추상화 시킬 필요는 없다. YAGNI원칙을 따라라.
코드를 작성하는 것은 문제를 해결하는 값비싼 방법이다. 해결책에 필요한 코드가 적고 간단할수록 더 좋다.
- 의존성을 목으로 처리할 필요가 없는 한, 프로세스 외부 의존성에 대한 인터페이스를 두지 말라. 결국 비관리 의존성에 대해서만 인터페이스를 쓰라는 지침이 된다.
- 관리 의존성은 명시적으로 주입하고, 해당 의존성을 구체 클래스로 사용하라.
8.5 통합 테스트 모범 사례
- 항상 도메인 모델을 코드베이스에서 명시적이고 잘 알려진 위치에 두도록 하라.
- 애플리케이션에 추상 계층이 너무 많으면 코드베이스를 탐색하기 어렵고 아주 간단한 연산이라 해도 숨은 로직을 이해하기가 너무 어려워진다.
- 추상화가 지나치게 많으면 단위 테스트와 통합 테스트에도 도움이 되지않는다. 간접계층이 많은 코드베이스는 컨트롤러와 도메인 모델 사이에 명확한 경계가 없는 편이다.
- 대부분의 백엔드 시스템에서는 도메인 모델, 애플리케잉션 서비스 계층(컨트롤러), 인프라 계층, 이 세가지만 활용하면 된다.
참고
백엔드 개발자 입니다