웹 계층 개발 완료 그리고 테스트
오늘은 드디어 내가 생각한 웹 계층 개발을 모두 마쳤다. 내가 생각한 테스트까지 모두 작성 완료하였다. 이전의 고민과 겪은 시련(?)들 덕에 남은 기능 개발 및 테스트는 그렇게 큰 문제 없이 개발 할 수 있었다. 하지만 개발을 하면서 고민이 안됬다는 것은 아니다.
ProductQueryController 개발
여러 값을 입력받을 수 있는 ProductCategory 를 활용한 조회 기능
어제 ProductQueryController 개발 사항들 중, 특정 Product 조회 기능에 대한 테스트 및 개발을 완료하고 또 기록까지 끝냈다. 그리고 남은 ProductCategory 를 활용한 Product 조회 기능을 오늘 개발 하였다.
이번 개발을 진행하면서, 느낀점은 쉬우면서도(?) 어려웠다.
쉽다고 느낀 부분은 그냥 내가 개발할 기능이 너무 간단하다는 것이다. 웹 계층을 개발하는 것이므로, 나는 웹계층만 신경쓰면된다. 신경써야하는 부분(책임)을 간단하게 이야기한다면, 입력 값을 잘 받고, 반환만 잘하면된다.
- HTTP 요청을 자바 객체로 매칭하고, 출력을 처음과 반대로 HTTP로 매핑한다.
근데 내가 어렵다고 느낀 부분은 나머지 모든 부분이다. 이렇게말하고보니 어려웠다고 보는게 맞는 것 같기도.. 하다.. 나는 특히 입력 유효성 검사를 어디서 해야할 지 고민이 되었다. 유효성 검사의 책임에 관해 지난 다른 계층 개발 간 고민한 적이 있는데, 당시 유효성 검사 요소로는 필드값의 유효 여부(NotNull)만을 확인했었다. 하지만 이번 기능을 개발하면서 다른 유효성 검사가 필요함을 깨닫게 되었다.
유효하지 않는 ProductCategory 의 조회
유효하지 않는 ProductCategory 의 유효성 검사는 TrackProductListQuery 에서 책임지도록 나는 설계를 했었다. 입력 값이 유효하지 않다면, ProductDTOException 을 발생시키고, TrackProductListQuery 가 생성되지 않도록 만들었다.
하지만 개발을 하면서 첫번째 고민이 생겼다. 나는 입력 값으로 여러 ProductCategory 를 입력 받게하는데, 다수의 ProductCategory 중, 유효하지 않은 ProductCategory 가 여러개인경우 유효하지 않은 모든 정보를 같이 반환하는 것이 더 맞지 않을까? 하는 생각이들었다. 한번에 하나의 유효하지 않음을 알리는 것이 맞나? 하는 생각과 함께 말이다.
나는 이에 대하여, 전자를 채택하기로 하였다. 그 이유는 한번의 요청을 통해 잘못된 정보를 한번에 식별해주는 것이 맞다는 생각이 들었기 때문이다. 그리고 후자는 불필요한 요청을 만들어 내는 행동이라는 생각했다.
그리고 난 뒤 두번째 고민은 스프링에서는 GET 파라미터를 어떻게 받는거지? 하는 고민이 되었다. 스프링을 활용한 개발이 처음이라, 기초적인 부분임에도 불구하고 순간 멍.. 해졌었다. 또 이를 어떻게 테스트해야하지? 이게 고민 세트였다. 하지만 이 문제는 GPT를 통해 쉽게 해결할 수 있었다.
정상 ProductCategory 를 통한 Product 조회 의 경우, 너무 길어 비교적 간략한 존재하지 않는 ProductCategory 를 사용한 경우의테스트를 캡쳐했다. 그런데 지금 보니깐 이 테스트는 깨지기 쉬운 테스트인것같다. message 부분이 잘못됬다. 지금 테스트에서는 단일 Category 를 검증했는데, 여러 카테고리일 경우를 커버하지 못한다. 수정해야겠다.
나는 이렇게 기능 개발을 마무리했다. 그런데 지금보니깐 메서드 명이 조금.... 개선의 여지가 많아보인다. 이 부분도 개선해야겠다..
ProductCommandController 개발
ProductQueryController 의 개발을 마치고, Product 개발의 마지막(?) ProductCommandController 개발을 시작했다. CommandController 에서는 상태를 변경하는 요청, Product 의 생성 및 수정 API 를 책임하도록 설계하였다.
그리고 오늘 대부분의 고민과 이슈는 CommandController 를 개발하면서 발생했고, 문제가 됬던 부분은 DTO 객체의 역직렬화 부분 이었다.
JSON 변환 과정 중, CreateProductCommand 객체를 생성할 수 없다 는 오류가 발생했다.
에러 메시지의 마지막에서는 생성자가 없다고 하였다. 나는 의문이었다.. 아니 나는 분명 생성자가 존재하는데..? 뭐지..?
나는 의문이 들었다. 왜 생성자가 있는데 없다고 하는거지? 일단 에러를 해결하기 위해, @AllArgsConstructor 를 붙여보았는데, 해당 에러는 사라졌다. 그리고 나는 다음 문제를 해결하기 위해 넘어갔다. 이 어노테이션이 다른 기능에 영향을 줄 수있지 않은가? 하는 고민은 이전에 작성한 CreateProductCommandTest 를 포함한 전체 테스트에 이상이 없음을 확인했기 때문이다. 역시.. 테스트가 아주 훌륭하다.
하지만 문제는 여기서 끝나지 않았다. CreateProductCommand 의 price 필드 값을 Money 객체로 역직렬화를 할 수 없었다. 처음에는 이것이 왜 안되는 것일까... 궁금하고.. 또 모르겠어서 GPT에게 물어보니, 이는 자동으로 역직렬화가 되지 않는다고 한다.
생각해보면 입력값으로 오는건데, Java 객체로 매핑을 또다시 한다는게 가능한가? 싶다. 그래서 해당 부분을 모두 수정했다.
이 부분을 수정하면서, 테스트의 위엄을 또다시 느낄 수 있었다. 오류가 발생하는 곳을 모두 수정하고, 맘편히 개발을 계속했다. 근데 고민은 얼마지나지않아 바로 또다시 생겼다.
테스트에서는 이 Json 입력 값을 body에 어떻게 할당해야하지? 하는 고민에 빠졌다. 처음에는 HashMap 을 활용하여 content 를 만들고, ObjectMapper 를 통해 JSON String 으로 변환하고, 해당 변환 값을 content 로 지정하였다. 근데 이것이 CreateProductCommand 객체로 된다는 것을 확신할 수 없었다.
나는 해당 고민을 GPT에게 이야기했고, GPT는 아주 친절하게 더 좋은 방법을 알려주었다. 나는 ObjectMapper 의 writeValueAsString() 메서드를 사용했는데, 이 메서드는 객체를 JSON String 으로 만들어 준다. 그리고 이말은 즉슨, CreateProductCommand 객체 또한 JSON String 으로 변환이 가능함을 의미했다. 이렇게 하니 아주 내망에 쏙 드는(?) 테스트를 작성할 수 있었고, 기능을 검증하고 해당 기능을 마무리 할 수 있었다.
나머지 updateProduct 의 경우도 createProduct 와 크게 다른 것이 없었다. UpdateProductCommand 또한 price 필드가 잘못됬었고, 같은 인스턴스를 생성할 수 없다는 에러가 발생했다. 그리고 같은 방법을 통해 문제를 해결했다.
이렇게 나는 내가 처음 목표한 Product 도메인의 웹계층 개발을 완료하였다.
벌써 휴가철이라고 한다. 그리고 부모님은 여름 휴가로 시골에 내려가셨다. 나도 가고싶었지만.. 지금은 이것을 더 하고싶었다. 부모님 휴가기간 모두 시골에 계시는 것은 아니니깐, 하루정도는 부모님과 함게 쇼핑도하고 식사도 해야겠다.
원래 계획이라면.. 지금은 Order 도메인을 다 마치고, 이력서까지 반영하고서 슬슬 이력서도 넣고 면접준비를 해야하는데, 너무 늦어진것같다. 비록 늦었지만 더 확실하게 해야겠다. 그래도 부족한 부분이 많겠지.. 부족한 부분을 스스로 채워나갈 수 있는 멋진 개발자가 되어보자!! 내일은 PR 작성하고 리뷰를 요청해야지! 그리고, Order 가즈아 !!!
잊지말자, Product 문서정리, Issue 개발!!