[코드숨 스프링 15기] 4주차 회고

1. 과제

 지금까지 배운 내용을 토대로 '고양이 장난감 가게' 어플리케이션을 개발하라.

 

2. 배운점

2.1. 계층별 단위테스트 방법

 - 계층별 단위테스트 방법을 알게되었다. 일반적으로 각 계층은 하위 계층에 의존적이다. 클린 아키텍쳐로 구성한 고양이 장난감 가게는 Web,  Controllers, Use Cases, Entites 계층으로 구성되었으며, 계층별 단위테스트 방법을 익혔다.

출처 : http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

1) Web

 mockMvc 와 Mock Service(Use Cases)로 테스트하였다. mockMvc는 서블릿 컨테이너의 구동 없이 HTTP 서블릿 요청과 응답을 제공하는 유틸리티 클래스이고, Mock Service는 Controller가 의존하는 Service를 Mocking 한 객체이다. Web 어플리케이션의 REST API 호출 테스트가 목적이기에 실제 Service 로직을 확인할 필요가 없으므로 Mocking한다.

 

2) Controllers

 Controller와 Mock Service(Use Cases)로 테스트하였다. 위와 마찬가지로 Controller 테스트가 목적이기에 Service를 Mocking 하였다. Controller가 의존하는 Service에 대해서는 메서드 호출 여부만 확인하면 된다. 확인이 필요한 메서드는 verify 메서드를 통해 확인하였다.

 초기 테스트 코드에는 Controller가 호출하는 모든 Service 메서드에 대해 verify 검증을 하였으나, Mock Service의 메서드에 Stubbing을 하여 응답 지정하고, 테스트를 통해 이 값을 받는 행위 자체가 Service의 메서드를 호출한 것이므로 메서드 검증을 할 필요가 없었다. 해서 응답 값이 없거나, 확인이 어려운 메서드에 대해서만 verify로 검증하였다.

 

3) Use Cases(Service or Application)

 Service와 Mock Repository로 테스트하였다. Service 테스트가 목적이기에 의존하는 Repository를 Mocking하였다. 마찬가지로 응답값이 없거나, 확인이 어려운 메서드에 대해서만 verify로 검증하였다.

 

4) Entities

 Repository와 서버 방식의 h2 DB로 테스트하였다. JPA를 사용하는 경우 JPA에서 지원하는 CrudRepository 같은 클래스를 상속받아 가져다 쓰므로 사실 검증할 필요가 없다. 단, 직접 쿼리를 작성할 경우에는 검증이 필요하다.

 

3. 느낀점

 비록 매우 단순하지만 클린 아키텍쳐가 적용된 프로그램의 단위 테스트코드를 작성해봄으로써 테스트코드에 대한 메커니즘을 이해할 수 있었다.

 필자는 이번 과제 중 Repository에 대한 테스트가 계속 실패하는 이슈가 있었다. 도저히 이해가 되지 않아 필자가 모르는 JPA의 영속성 컨텍스트 이슈로 판단하였고, 멘토님께 도움을 요청하였다.

 원인은 단순 테스트 데이터를 Insert하는 부분이었으며, 인메모리가 아닌 실제 DB 서버 방식으로 변경 후 디버깅하며 DB 데이터를 확인한 결과 필자가 예상하지 못한 데이터가 들어있었다. 데이터가 이렇게 들어간 원인도 정말 너무 단순했다.

 멘토님의 피드백 중 Repository 테스트 방식에 대해 언급해주신 내용이 있다. DB를 인메모리 방식의 h2를 많이 사용하나 개발자가 생각한 동작과 다를 수 있다는 점에서 실제 DB 서버와 연결하여 사용하는 것을 권장한다는 것. 이 내용이 사실 와닿지 않았지만, 내가 한 짓을 통해 단박에 이해하게 되었다! 5주차도 열심히!