7-아키텍처 요소 테스트하기

테스트 피라미드

단위 테스트:
- 피라미드의 토대
- 일반적으로 하나의 클래스를 인스턴스화하고 해당 클래스의 인터페이스를 통해 기능들을 테스트한다.
- 만약 테스트 중인 클래스가 다른 클래스에 의존한다면 의존되는 클래스들은 인스턴스화하지 않고 테스트하는 동안 필요한 작업들을 흉내 내는 목으로 대체한다.
통합 테스트:
- 여러 유닛을 인스턴스화하고 시작점이 되는 클래스의 인터페이스로 데이터를 보낸 후 유닛들의 네트워크가 기대한대로 잘 동작하는지 검증한다.
- 이 책에서 정의한 통합 테스트에서는 두 계층 간의 경계를 걸쳐서 테스트할 수 있기 때문에 객체 네트워크가 와넞ㄴ하지 않거나 어떤 시점에는 목을 대상으로 수행해야 한다.
시스템 테스트:
- 애플리케이션을 구성하는 모든 객체 네트워크를 가동시켜 특정 유스케이스가 전 계층에서 잘 동작하는지 검증한다.
- 시스템 테스트 위에는 애프리케이션의 UIㄹ르 포함하는 엔드투엔드 테스트 층이 있을 수 있지만, 백엔드 아키텍처에 대해서 논의하고 있으므로 엔드투엔드 테스트에 대해서는 고려하지 않기로 한다.

단위 테스트가 도메인 엔티티에 녹아 있는 비즈니스 규칙을 검증하기 가장 적절한 방법이다.
- 테스트를 만들고 이해하기 쉬운 편이고, 아주 빠르게 실행된다.
도메인 엔티티의 행동은 다른 클래스에 거의 의존하지 않기 때문에 다른 종류의 테스트는 필요하지 않다.

Mockito 라이브러리를 통해 목 객체에 대해 특정 메서드가 호출됐는지 검증한다.
이 테스트는 행동 변경뿐만 아니라 코드의 구조 변경에도 취약해진다.
- 따라서, 테스트에서 어떤 상호작용을 검증하고 싶다면 모든 동작을 검증하는 대신 핵심만 골라 집중해서 테스트하는 것이 좋다.

웹 어댑터는 JSON 문자열 등의 형태로 HTTP를 통해 입력을 받고, 입력에 대한 유효성 검증을 하고 ,유스케이스에서 사용할 수 있는 포맷으로 매핑하고, 유스케이스에 전달한다.
웹 컨트롤러가 스프링 프레임워크에 강하게 묶여 있기 때문에 격리된 상태로 테스트하기 보다는 이 프레임워크와 통합된 상태로 테스트하는 것이 합리적이다.

웹 어댑터와 같은 이유로 통합테스트로 작성한다.
데이커베이스를 모킹하지 않는다.
- 실제 데이터베이스와 연동했ㅇ르 때 SQL 구문의 오류나 데이터베이스 테이블과 자바 객체 간의 매핑 에러 등으로 문제가 생길 확률이 높다.
프로덕션 환경에서는 인메모리 데이터베이스를 사용하지 않고, 인메모리 데이터베이스에서 테스트가 통과했더라도 실제 데이터베이스에서는 문제가 생길 가능성이 높기 때문에 Testcontainers 같은 라이브러리로 데이터베이스를 도커 컨테이너로 띄워서 테스트 할 수 있다.

시스템 테스트는 단위 테스트와 통합 테스트가 발견하는 버그와는 또 다른 종류의 버그를 발견해서 수정할 수 있게 해준다.
- 예) 계층 간의 매핑 버그 등
시스템 테스트는 여러 개의 유스케이스를 결합해서 시나리오를 만들 때 더 빛이 난다.
- 시스템 테스트를 통해 중요한 시나리오들이 커버된다면 최신 변경사항들이 애플리케이션을 망가뜨리지 않았음을 가정할 수 있고, 배포될 준비가 됐다는 확신을 가질 수 있다.

얼마나 마음 편하게 소프트웨어를 배포할 수 있느냐를 테스트의 성공 기준으로 삼으면 된다.
프로덕션 버그에 대해서 “테스트가 이 버그를 왜 잡지 못했을까?“를 생각하고 이에 대한 답변을 기록하고, 이 케이스를 커버할 수 있는 테스트를 추가해향 한다.
우리가 만들어야 할 테스트를 정의하는 전략으로 시작하는 것도 좋다. 다음은 육각형 아키텍처에서 사용하는 전략이다.
- 도메인 엔티티를 구현할 때는 단위 테스트로 커버하자
- 유스케이스를 구현할 때는 단위 테스트로 커버하자
- 어댑터를 구현할 때는 통합 테스트로 커버하자
- 사용자가 취할 수 있는 중요 애플리케이션 경로는 시스템 테스트로 커버하자
리팩터링할 때마다 테스트 코드도 변경해야 한다면 테스트는 테스트로서의 가치를 잃는다.