Layered Architecture 구조의 레이어별 테스트 작성법을 알아보았습니다. 레이어별로 1) 어떤 특징이 있고, 2) 어떻게 테스트를 하면 좋을지, 자기만의 언어로 다시 한번 정리해 볼까요?

레이어별 특징과 역할

• Persistence Layer
  • 데이터의 생성, 조회, 수정, 삭제에 관한 처리
• Business Layer
  • 비즈니스 로직 수행
    • 도메인에 맞는 검증 처리
  • 트랜잭션 처리
• Presentation Layer
  • 사용자의 요청을 받는 곳
  • 사용자 요청에 대한 간단한 검증(null, 타입, blank 검증 등)
  • 앤드포인트 처리

레이어별로 어떻게 테스트를 하면 좋을지

• Persistence Layer
  • 데이터의 CRUD를 정확하게 수행하는지 확인하는 테스트
• Business Layer
  • 비즈니스 로직이 의도한 대로 수행하는지 확인(해피케이스) 테스트
  • 객체 간의 협력이 정확하게 이루어 지는지 확인하는 테스트
  • 의도한 예외 처리가 이루어지는지 확인하는 테스트
  • 외부 API 등 테스트가 어려운 경우 책임 분리와 Mocking 활용
  • 객체와 레이어 간 협력 관계 고려
    • 데이터 전달 방식 설계(파라미터, DI)
• Presentation Layer
  • 사용자 요청의 정상 처리 검증(해피케이스)
    • 엔드포인트 정확성 확인
  • 사용자 요청에 대한 예외 처리 테스트(null, 타입, blank 검증 등)

테스트에 대한 접근

이전 사이드 프로젝트에서 사용자 통계(n개월간의 게시글, 댓글, 좋아요 수의 변화 추이)를 데이터베이스의 집계 함수를 활용해 처리했습니다. 이러한 설계를 선택한 이유는 다음과 같습니다:

1. 대용량 데이터 처리에서 데이터베이스가 일반적으로 더 나은 성능을 보입니다.
2. 단순한 월별 수치만 필요했기 때문에, 애플리케이션 서버에 불필요한 자원을 가지지 않게 하기 위해서 입니다.

이 설계는 강의에서 말씀해주셨던 'Persistence Layer에서는 비즈니스 가공 로직이 포함되어서는 안 된다'는 원칙에 모호한 경계선에 있다고 느꼈습니다. 집계가 과연 비즈니스 로직으로 봐야 하는지, 아니면 단순한 조회 로직으로 봐야 하는지에 대해서는 경계가 모호합니다. 제가 내린 결론은 단순 집계를 수행하는 것은 비즈니스 로직보다는 Read의 역할을 한다고 생각합니다. 테스트 코드의 작성은 관심사, 책임의 분리부터 시작된다고 생각합니다. 레이어의 분리 뿐만 아니라 클래스 분리, 기능 분리 등 책임을 어떻게 나눌지 설계가 적절히 이루어져야 좋은 테스트 코드가 작성될 수 있다고 생각합니다.