7. 아키텍처 요소 테스트하기
기본 전제
- 만드는 비용이 적고
- 유지보수 하기 쉬워야 하며
- 빨리 실행되고 안정적인 작은 크기의 테스트들에 대해 높은 커버리지를 유지해야 한다.
테스트 피라미드
- 시스템 테스트 : 애플리케이션을 구성하는 모든 객체 네트워크를 가동시켜 특정 유스케이스가 전 계층에서 잘 동작하는지 검증
- 통합테스트: 연결된 여러 유닛을 인스턴스화하고 시작점이 되는 클래스의 인터페이스로 데이터를 보낸 후 유닛들의 네트워크가 기대한대로 잘 동작하는지 검증
- 단위테스트 : 하나의 클래스를 인스턴스화하고 해당 클래스의 인터페이스를 통해 기능들을 테스트
클린 아키텍처 기준
- 단위 테스트 : 특정 코드의 중요한 로직들이 의도한대로 별도의 외부 의존성 없이 제대로 돌아가는지 검증이 필요한 경우, 도메인 엔티티 테스트, 유스케이스 테스트
- 통합 테스트 : 웹 어댑터, 영속성 어댑터와 같이 외부 클라이언트와 상호작용을 통해 검증이 필요한 경우
- 시스템 테스트 : 전체 애플리케이션을 띄우고 API를 통해 요청을 보내고 모든 계층이 조화롭게 잘 동작하는지 검증
앞서 단위, 통합 테스트를 잘 구현했다면 시스템 테스트는 일부 겹치는 로직도 있지만 단위,통합만으로 알아차리지 못한 계층 간 매핑 버그 같은건 시스템 테스트를 통해서 알게되는 경우도 있다.
시스템 테스트를 통해 중요한 시나리오들을 모두 커버하면 배포할 준비가 된것이다.
단순히 라인 커버리지를 100%로 만드는 것을 목표로 테스트하는건 잘못된 지표이다.
처음 몇번의 배포는 믿음의 도약을 하고 이후 버그를 수정하고 이로부터 배우는 것을 목표로 삼는 다면 제대로 가는 것이다.
“테스트가 이 버그를 왜 잡지 못했을까?” 를 생각하고 이에 대한 답변을 기록하고, 이 케이스를 커버할 수 있는 테스트를 추가해야 한다.
새로운 필드를 추가할때마다 테스트를 고치는데 한 시간을 써야 한다면 뭔가 잘못된것이다.
테스트가 구조적 변경에 너무 취약하여 리팩토링할 때마다 테스트 코드도 변경해야 한다면 테스트로서의 가치를 잃는다.
헥사고날 아키텍처는 도메인 로직과 바깥으로 향한 어댑터를 깔끔하게 분리하여 핵심 도메인 로직은 단위 테스트로, 어댑터는 통합 테스트로 처리하는 명확한 테스트 전략을 정의할 수 있다.