영암사는 승경이네

1. 과제

 어플리케이션을 문서화하고 Docker를 사용하여 빌드하라.

2. 배운점

2.1. 도커 개념

 도커, 도커 파일, 도커 이미지, 컨테이너와 같은 개념을 정리하였다.

2.2. 문서화

 JavaDoc를 사용해 주석들을 문서화하고,  asciidoctor를 사용해 API도 문서화하는 방법을 알아보았다.

3. 느낀점

 사실 asciidoctor를 통해 API 문서화 방법을 실습하면서 'Swagger를 통해 API 문서를 생성하는 방법을 알려주는게 더 좋지 않았을까' 라는 생각이 많이 들었다. javaDoc과 같은 경우는 API 명세 뿐 아니라 비지니스 로직에 대한 명세도 상세히 기입할 수 있어 이점이 있으나, asciidoctor과 같은 경우는 개발자가 작성한 테스트 코드를 통해 API 명세를 제공하여 누락될 여지가 있고, 실제 API 테스트도 Swagger가 훨씬 간편하기 때문이다.

 도커의 개념, 도커 파일, 이미지 생성, 컨테이너 빌드에 대한 내용이 한 시간 남짓한 강의로 제공되었는데, 강의의 코드를 보고 따라치는 느낌이라 도커에 대한 자세한 내용은 얻어갈 순 없었다. 도커에 대한 일반적인 프로세스 및 개념정도의 이해를 목적으로 한 것 같았다.

 이로써 마지막 8주차 강의까지 모두 끝이났다. 8주간 받았던 피드백들 하나하나 정말 소중했고, 특히 테스트 주도 개발을 위해 어떻게 시작해야 할지에 대한 방향이 잡힌 것 같다. 8주의 기간동안 받았던 피드백들을 다시한번 복기하며 정리하여 추후 있을 토이 프로젝트 배운 내용을 적용할 수 있도록 할 것이다.

1. 과제

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

2. 배운점

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

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

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주차도 열심히!

1. 과제

 객체지향적인 REST API를 스프링 부트로 구현하라.

2. 배운점

2.1. HTTP Status 를 개념있게 사용하자

 서버 오류가 발생했을 때는 500, 리소스가 없을때는 404, 성공했을 때는 200, 요청 값이 비정상적일때는 400. 개발을 하면서 내가 접했던, 그리고 아는 HTTP Status는 딱 이정도였다. 이번 과제를 진행하며 처음으로 201, 204 등의 코드를 접해보았으나 의미와 개념을 파악하지 않고 '메서드에 따라서 상태코드가 달라질 수 있구나' 라고만 생각하고 넘겼다.

알고보니 201은 요청성공 및 리소스 생성일때, 즉 Create한 요청을 보냈을 때의 상태코드이고, 204는 요청 성공했으나 응답값이 없을 때, Delete한 요청을 보냈을 때 사용 가능한 상태코드이다. 404도 클라이언트 자원(html, css, img 등)이 없을 때의 상태코드로 알고있었으나 클라이언트 자원 뿐 아니라 서버 리소스가 없을 때도 404 상태코드로 표현이 가능했다.

이를테면 id에 매핑된 정보를 수정요청할 때 서버에서 유효한 id 값인지 확인하게되는데 이 값이 없을 경우 상태코드를 404로 리턴해도 된다.

 100번 대는 정보응답, 200번 대는 성공, 300번 대는 리다이렉트 400번 대는 클라이언트 에러, 500번 대는 서버 에러로 백의자리 숫자에 따라 상태코드가 구분된다는 것도 처음 알게 되었다.

아래는 HTTP 상태코드에 대한 공식문서이다.

https://developer.mozilla.org/ko/docs/Web/HTTP/Status

2.2. 스프링 부트야 고맙다.

 1주차에서는 스프링 없이 Java로만 코드를 짜다보니 코드가 길어지고 시간도 많이들었다. 이번 주차에 스프링 프레임워크를 사용하니 훨씬 쉽고 깔끔한 코드를 구현할 수 있었다. 나쁘게만 보였던 스프링 부트가 조금은 착해보인다.

2.3. 공식문서 보는 습관을 들이자.

 람다식을 사용하니 멘토님께서 공식문서 주소를 주시며 한번 봐보라고 하셨다. 하지만 필자는 공식문서의 영어가 보이는 순간 자신감을 잃는다. 한글로 번역을 때리면 코드들도 번역이 되기에 블로그를 기웃기웃 거렸다.

 하지만 생각과 달리 공식문서에서 제공되는 예제 코드들은 정말 간단하고 이해하기 쉽게 되어있었다. 설명들은 번역기로 돌려가며 이해했고, 코드들은 쭉 코딩해보니 맥락이 이해되면서 예제코드도 이해되기 시작했다. 그리고 무엇보다 간지가 좀 나는것 같다. 공식문서를 읽는 개발자... 아무쪼록 공식문서를 보는 습관을 들여보겠다!

3. 느낀점

이번 과제는 1주차보다 빨리 끝났다. 이유는 스프링 문법을 사용했기 때문이다. 생각없이 사용했던 어노테이션과 스프링 문법들에 대해 생각의 여지를 갖게 해준 시간이었던 것 같다.

 HTTP Status 코드를 새롭게 이해하게 됐고, 공식문서를 보는 게 얼마나 중요한 것인지도 알게되었다. 뭔가 다음주차부터는 큰 고통받을 것 같아 두려운 마음이 있지만 멘토님이 있으니 걱정안한다. -ㅅ-