본문 바로가기

전체 글196

Pull Request 016. Base Entity를 통해 데이터 생성일 / 수정일 설정하기 - 제어하기 어려운 코드 개선, static 메서드 mocking 테스트 해당 기능을 넣을까말까 고민을 많이 했다. 그런데 아무리 생각해도 결국에는 필요한 기능이 아닐까 싶어서 넣기로 했다. 문제는 향로님의 글을 보며 시간에 대한 테스트를 어떻게 해야할까에 대한 고민이 남아있었다는 것이다. 그런데 향로님이 아예 예시 코드를 남겨주시기까지 했는데 못 할 것 있나? 싶은 생각에 빠르게 돌입했다. 이번 포스팅에 앞서 이번 구현만큼은 TDD 방식으로 구현하지 못했음을 미리 알린다. 아예 새롭게 시도해보는 방법이었고, static메서드의 테스트도 처음 도전해보는 부분이라 거의 다른 분들의 코드를 따라하는 수준이었다. 참고한 글들은 글 말미에 남긴다. 데이터 생성일과 수정일은 모든 엔티티에 적용되어야 한다. 따라서 모든 엔티티의 상위 엔티티가 될 Base Entity를 먼저 만들었다... 2023. 11. 28.
Pull Request 015. API 문서화 적용하기 - Spring Rest Docs API 문서화를 위해서는 크게 두 가지 방법이 있다. 하나는 이번 포스팅에서 서술할 Spring Rest Docs를 사용하는 것이고, 하나는 Swagger를 사용하는 것이다. 두 방법의 가장 큰 차이는 '문서화를 위한 코드를 어디에 작성할 것인가?'에 있다. Swagger는 프로덕션 코드에 문서화를 위한 코드를 작성한다. Spring Rest Docs는 테스트 코드에 문서화를 위한 코드를 작성한다. 이번 프로젝트에는 Spring Rest Docs를 적용해볼 예정이다. 애초에 TDD 구현 방법을 연습하기 위해 모든 경우에 테스트 코드를 먼저 작성할 예정이고, 기왕 테스트 코드를 작성한 김에 테스트 코드에 문서화 코드까지 적용시키는게 낫겠다고 생각했기 때문이다. 또한 많은 분들이 Swagger의 UI만을 이.. 2023. 11. 28.
Pull Request 014. 게시판 테이블 상속하기 여러 게시판을 만들기로 결정한 후로, 테이블 상속과 관련하여 고민이 많았다. 게시글 엔티티의 구성요소에는 '게시글 id', '작성자', '제목', '내용', '댓글' 이 겹쳤다. 거의 다 겹쳤다고 보는게 맞다. 위의 초기 디자인을 보면 알 수 있듯이, 정말 많은 부분이 서로 다른 게시판에 공통적으로 포함됐다. 자연스럽게 게시판은 상속의 형태로 구현해야겠다고 생각했다. 마침 JPA에서 상속을 사용하는 방법에 대해 공부한 참이었다. 이를 적절히 적용해볼 수 있겠다 싶었다. 상속 전략은 단일 테이블 전략을 선택했다. 단일 테이블 전략을 선택한 이유는 다음과 같다. 단일 테이블 전략의 가장 큰 단점은 '테이블 하나가 지나치게 비대해질 수 있다'는 점과 'null을 허용해야 한다.'는 점이다. 내가 생각했을 때,.. 2023. 11. 27.
Pull Request 013 - 자유 게시글 수정 기능 컨트롤러 계층 TDD로 구현하기 수정 기능의 테스트를 만들고 기능을 구현해보자. 수정 기능의 수행 과정은 다음과 같다. HTTP 메서드는 PUT메서드를 사용한다. urn은 /free-board/{free-board-id}를 사용한다. FreeBoardController#putFreeBoard(long freeboardId, FreeBoardDto dto); 메서드에서 Put DTO를 받아와 FreeBoard Serivce에 넘겨주고 Response DTO를 받아온다. 받아온 Response DTO를 ResponseEntity객체로 변환해 반환한다. 이 때, HttpStatus는 OK로 설정한다. 수정에 PATCH 대신 PUT 메서드를 사용하는 이유는 다음과 같다. 우리가 정보 수정을 하는 경우를 생각해보면, 특정한 블록만 수정 할 수 .. 2023. 11. 27.
HTTP PUT 메서드로 자원을 수정할 때의 응답 : 200 vs 201 vs 202 수정 메서드를 작성하면서 PUT을 사용하기로 결정한 뒤로 HTTP 응답 상태 코드에 대한 고민은 크게 하지 않았는데, 이번에 해당 기능을 구현하면서 고민을 좀 했다. 200이 맞을까, 201이 맞을까, 아니면 202가 맞을까? 관련해서 상태 코드에 대한 공부도 겸할 수 있었다. 여러 자료와 글들을 읽어보았고, 두 글을 통해 나름대로 해답을 내렸다. 아무튼 수정이 잘 되면 200을 보내는게 맞다. 200은 말 그대로 OK다. 서버에서 '그래그래 형이야. 형은 실제로 클라이언트가 요청한 일을 전부 처리했어.' 라고 하면 200 OK를 보낸다. 이 과정에서 새롭게 생긴 자원이 있으면 안된다. 새롭게 생긴 자원이 있으면 201로 넘어간다. 201은 CREATED다. 일단 앞까지는 똑같다. '그래그래 또 형이야... 2023. 11. 27.
[11/21 TIS] 아니 그니까 그게 왜 비어있는데요; - 메소드 mocking 시 객체를 넘겨주려면 equals()와 hashCode()를 구현하라 컨트롤러 계층의 테스트를 만들면서, 내가 생각한대로 테스트가 작동하지 않았다. 이게 분명히 테스트가 통과되어야 할 것 같이 구현했는데, 자꾸 통과하지 못하는 것이다. 뭐가 문제인지 콘솔을 살펴보니 Response Body가 통째로 비어있었다. 이게 뭔 일인가 싶어 Postman을 켜서 같은 동작을 수행해보았다. 이러면 기능 구현에는 문제가 없어보였다. 테스트 코드에 뭐가 문제인지를 알아야했다. 이럴 때는 2023년에 살고있는게 참 좋다. 구글은 검색하면 다 알려준다. 관련해서 참고한 두 글의 링크를 남겨놓는다. https://velog.io/@devmizz/Spring-WebMvcTest%EC%97%90%EC%84%9C-Response-Body%EA%B0%80-Empty%EC%9D%BC-%EB%95%8C.. 2023. 11. 21.
반응형

티스토리툴바