인프런 워밍업 클럽 백엔드 2기 클린코드, 테스트 코드 참여 미션 수행 중 하나입니다!

관련 강의 :Practical Testing: 실용적인 테스트 가이드( https://www.inflearn.com/course/practical-testing-%EC%8B%A4%EC%9A%A9%EC%A0%81%EC%9D%B8-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EA%B0%80%EC%9D%B4%EB%93%9C/dashboard)

1. Layered Architecture ?

소프트웨어 개발 방법 중 하나로, 계층(Layer) 의 수에 따라 N-tier Architecture 부르기도 한다.

계층은 어떻게 나누는 것인가? - 책임에 따라서 나눈다.

강의에서는 3-tier Architecture 기준으로 나누었다. (Persistence, Business, Prsentation)

2. Layer(Persistence, Business, Prsentation)

1. Persistence Layer

책임 : 도메인(객체)의 생성과 검증

• 도메인의 생성과 관련된 책임을 가진 계층이다.

• 애플리케이션에서 생성한 객체(Domain)이 데이터베이스에 올바르게 저장되는지 검증하는 과정이 필요하다.

• Persistent Layer 는 객체가 어떻게 저장되고, 어떤 파라미터를 필요로하는 지 이해할 수 있는 계층이다.

• 테스트 코드 작성을 통해, Business 계층에서 사용될 객체들에 대해 이해를 가질 수 있는 계층이라 생각한다.

• 뒤에 올 Business, Presentation 계층의 작성을 위한 기본적인 토대를 제공하는 계층이다.

• 따라서, 이어질 계층에서 도메인에 대한 고민을 할 필요 없도록 테스트 코드를 작성해주는 것이 필요하다고 생각한다.

2. Business Layer

책임 : 도메인의 비지니스 로직 수행

• 객체의 생성과 검증이 완료된 토대에서, 서비스의 로직 을 수행하는 책임을 가진 계층이다.

• Persistent Layer에서 검증되고, 생성된 객체가 수행하는 책임을 검증하는 계층이라고 볼 수 있다.

• 그렇기에, 코드의 양이 많고 테스트 코드 작성도 복잡해진다.

• Service(Business)은 Persistent(Repository) 의존한다.

• 즉 2개의 계층이 테스트에 필요해진다.

• 중요하다고 생각하는 지점은, 이 계층은 비지니스 로직 에 집중해야 하는 계층이라는 점이다.

• 객체의 생성과 관련된 코드는 감추고 , 로직과 관련된 코드는 표현되어야 한다.

• 강의를 들으면서, 책임을 어떻게 분리할 것인가? 라는 의문이 생길 수 있다고 생각했다.

• 비지니스 계층을 작성하면서, 도메인과 비지니스 그리고 로직과 로직 사이의 리팩토링이 많이 이루어 질 수 있다고 생각!

   

3. Presentation Layer

책임 : 생성과 로직이 처리된 데이터의 출력

• 2 계층에서 생성되고, 처리된 데이터가 올바르게 생성되거나 프런트엔드에 올바르게 반환되는지 확인하는 책임을 가진 계층

• Business 계층에 의존한다.

• Business Layer 테스트에서 주의해야 할 점과 같이, Presentation Layer 검증에 집중해야 한다.

• 하지만, Business Layer의 특징은 복잡하다는 것이 있었다. 대체(Mock)개념의 필요성

• Presentation Layer 계층의 테스트에 집중하기 위해 Mockito 를 활용하여, 가짜 객체를 생성하고 테스트에 도입한다.

• 결국 데이터의 바인딩(Binding), 맵핑(Mapping) 에 집중해야 한다.

• API를 호출하면, 의도된 매개 변수를 받고 올바른 응답을 생성하는 과정을 검증할 수 있어야 한다.