이 글은 박우빈님의 강의를 참조하여 작성한 글입니다.

미션 - Day 15

미션 내용

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

1. 계층별 특칭

Layered Architecture : Presentation Layer <-> Business Layer <-> Persistence Layer

Layered Architecture 는 3가지 계층으로 구성된다.

웹 클라이언트와 연결된 Controller 부분에 해당하는 Presentation Layer, 서비스의 비즈니스 로직을 처리하는 Business Layer, DAO에 해당하는 Persistence Layer가 있다.

이렇게 계층을 나누는 이유는 관심사의 분리이다. 관심사, 책임을 나누기에 테스트의 작성을 편리하게 하고 신뢰성을 높이고 유지보수 또한 수월하다.

Presentation Layer

• 외부 세계의 요청을 가장 먼저 받는 계층

• 파라미터에 대한 최소한의 검증을 수행한다.

Business Layer

• 비즈니스 로직을 구현하는 역할

• Persistence Layer와의 상호작용(Data를 읽고 쓰는 행위)을 통해 비즈니스 로직을 전개시킨다.

• 트랜잭션을 보장해야 한다.

Persistence Layer

• Data Access의 역할

• 비즈니스 가공 로직이 포함되어서는 안 된다. Data에 대한 CRUD에만 집중한 레이어

   

2. 어떻게 테스트를 하면 좋을지, 자기만의 언어로 다시 한번 정리해 볼까요?

하나의 모듈을 기준으로 독립적으로 진행되는 단위 테스트와 둘 이상의 여려 모듈이 협력하여 기능을 통합적으로 검증하는 통합 테스트가 있다.

각 계층에 대한 테스트는 다음과 같이 진행하면 좋을 거 같다.

• Persistance Layer -> Spring과 통합한 단독 계층 테스트(Spring, Jpa 등 활용한 DB 접근), 단위 테스트 성격

   

• Business Layer -> Persistence를 포함한 통합 테스트

   

• Presentation Layer -> 이외 계층을 Mocking한 단독 계층 테스트, 단위 테스트 성격

강사님의 의견과 유사한 생각을 가지고 있다. 위와 같은 생각은 다음과 같은 이유 때문이다.

이유

Persistence Layer는 DAO 관련 계층이다. 컨트롤러나 서비스 등 이외 계층과 협력할 필요가 없다. 그렇기에 스프링, JPA를 활용한 테스트를 진행할 수 밖에 없다.

A와 B 기능이 각각 있을 때, 정상적으로 동작할 수 있다. 하지만 A + B 와 같이 사용된다면 실제 결과는 어떻게 나올지 모른다. 이러한 여러 모듈이 복잡하게 상호작용할 수록 이를 예측하는 건 더 어렵다. 이처럼 Business Layer 와 Persistence Layer를 통합한 테스트를 진행하면 더 높은 신뢰성을 보장할 수 있다.

또한 Persistence Layer에 대한 테스트를 이미 작성했다면 굳이 Persistence Layer를 Mocking하지 않는 것이 더 비용적으로 합리적일 수 있다.

Presentation Layer는 외부 세계와 연결된 계층이다. 외부 세계로 받은 정보에 대한 검증이 필요하다.

도메인의 성격, 서비스에 대한 내용과는 무관하다. 따라서 굳이 도메인 관련 로직을 검증할 필요는 없다고 생각한다.

물론 각 모듈이 상호작용할 때와 각각 작용할 때는 다른 결과값이 나올 수 있기에 3가지 계층에 대한 검증을 한 번에 하는 것이 더 신뢰성을 보장할 것이다.

그렇지만 비용 또한 고려해야 하므로 수동 테스트로 마무리하거나 비용이 나오더라도 꼭 검증해야할 정도로 중요하다면 그때 모든 계층에 대한 통합 테스트를 작성하여 신뢰성을 보장하면 된다고 생각한다.