WIL - 레이어별 테스트 전략 (Unit, Integration, E2E)

이번에 새로 배운 것

테스트는 다 같은 테스트가 아니라는 것을 처음 깨달았습니다.

처음에는 그냥 “테스트 = 내 코드가 제대로 작동하는가”를 검증하는 것이라고만 생각했는데
이번 주에 도메인, 서비스, API 레이어를 분리해서 테스트하면서 각 계층이 담당하는 책임이 다르다는 것을 느꼈습니다.

이 차이를 직접 코드로 경험하면서 비로소 “왜 테스트를 이렇게 나눠서 하는가”가 이해되었습니다.

어떤 레이어에 어떤 테스트를 적용하는게 좋을까?

도메인 레이어를 테스트할 때:

서비스 레이어를 테스트할 때:

API 레이어를 테스트할 때:

각 레이어의 책임이 다르면, 그 책임을 검증하는 방식도 달라야 한다.

왜? 도메인은 순수하게, 빠르게, 외부 의존성 없이 테스트되어야 하기 때문입니다.

도메인은 순수해야합니다.
아무런 인프라 의존없이 객체들끼리의 협력을 테스트해야하기 때문에 단순한 유닛테스트가 가장 적절했습니다.

왜? 여러 도메인이 함께 작동할 때, 흐름이 제대로 연결되는지 확인해야 하기 때문입니다.

서비스는 실제 비즈니스를 많은 인프라와 도메인이 협력하며 만족합니다.
때문에 Spring 애플리케이션을 실제로 동작하고, 실제 인프라들을 활용하여 협력을 검증해야 한다고 생각했습니다.

왜? 실제 사용자가 API를 호출했을 때, HTTP 요청부터 응답까지 정말 작동하는지 확인해야 하기 때문입니다.

실제 사용자가 요청을 하는 프레젠테이션 레이어부터 검증합니다.
요청 형식, 응답 형식, 상태 코드 등 API 명세를 확인하고, 실제 요청을 보내보면서 정말 작동하는지를 판단합니다.

테스트는 검증 도구이자, 동시에 설계 도구입니다.

테스트를 나누는 것은 단순히 속도 때문만이 아니라, 각 레이어가 무엇을 책임지는지 명확히 하기 위함이었습니다.

처음에는 테스트가 코드를 확인하는 것이라고만 생각했는데, 이번 주를 지나면서 “테스트는 설계와 고민의 흔적”이라는 것을 느꼈습니다.

각 레이어별로 다르게 테스트한다는 것은, 결국 각 계층이 무엇을 책임지는지 명확히 하고 싶다는 아키텍처의 의지 표현이었던 것 같습니다.

앞으로 코드를 짤 때도, “이 부분은 어느 레이어의 책임인가”를 먼저 묻고, 그에 맞는 테스트를 작성해야겠다는 마음가짐이 생겼습니다.