장바구니 미션
ViewController는Configuration방식보다는 되도록 Controller를 작성해주는 것이 좋다. 해당 엔드포인트에 대한 컨트롤러가 중복될 수도 있고, 찾지 못할 수도 있기 때문이다.- admin용 응답과 서비스용 응답은 현재 응답이 같더라도, 다른 service, 다른 responseDto를 활용하는게 좋습니다. admin용 응답에는 더 디테일한 데이터가 들어갈 수 있고, 서비스용 메서드는 인증 절차와 같은 부수적인 기능이 포함될 수 있기 때문입니다.
- 오류메시지의 정보는 많이 넣어주자. 대신 클라이언트까지 전달되는 값은 보안상 부적절하니, Exception의 메시지 자체에는 오류 내용을 풍부하게 싣고 ExceptionHandler에서 사용자 메시지로 전달되는 부분을 변경하면 좋을 것 같다.
- 인증인가 부분은 특히 메시지에 신경을 써야한다. 오류에서 생성되는 메시지들이 공격자에게 유효한 정보를 주지는 않는지 점검해보자.
- jackson 2.13 릴리즈 패치에서 기본생성자 없이도 직렬화가 가능하도록 변경되었습니다https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.13#no-constructor-deserializer-module
의문점
- 인증 로직은 대체 어디에 있어야 할까? ArgumentResolver, Filter, Interceptor, AuthService?
- ArgumentResolver의 패키지 위치는 어딜까? (Controller, 혹은 다른 패키지?)
- audit이 필요한 이유?
테스트에서 데이터를 통해 의존성이 생기는 것은 주의하자. 인증 쪽에서 로그인을 해야 사용할 수 있다. 유저를 매번 생성하지 않고 미리 하나 만들어두고 재사용하는 방식을 사용한다. 테스트 스코프는 중요하다.
슬라이스 테스트가 의미가 있다고 생각하시는가? 컨트롤러 계층에 대한 테스트는 e2e 테스트로도 충분히 검증할 수 있다고 생각한다. 컨트롤러 mocking은 굳이 의미 없다고 생각한다. 그러나 컨트롤러에 로직이 들어간다면 그럴 수 있다. 서비스도 슬라이스 테스트가 의미 없다. 지금은 dao 에서 조회만 하고 있기 때문에 그렇다. 서비스에 로직이 들어가게 되면 의미가 있을 것이다. 그러나 그런 로직이 없기 때문에 더욱 의미가 없는 것처럼 느껴진다.
럿고
서비스 계층을 mocking을 하는 것 테스트는 현재에 대해서만 검증하면 된다고 생각하지만, 미래를 대비하는 역할을 한다. 그런 부분에서는 테스트 코드가 안정성이 더 중요하다. 더 꼼꼼하게 작성하자. slice 테스트든 뭐든 학습 목적으로는 많이 고민해보는 것이 좋다. 호되게 당해보는 것도 오히려 좋을 수 있다.
클라이언트에서 찾을 수 없는 id에 대한 업데이트와 삭제를 요청하는 경우, 현재는 404를 리턴하고 있는데, 200 ok나 500 예외를 던지는 것 중 어떤 것이 좋을까요? -> 404 Not Found body로 전달을 하게 된다면? -> update를 할 때도 URI에는 ID를 넣기 때문에(컨벤션) 해당 API가 존재하지 않는다는 뜻을 가지므로 괜찮다고 생각한다. HttpStatus Code에 대해 좀 더 알아보자.
DB는 최대한 데이터를 가공하는 것은 피하는 것이 좋다고 생각한다.
DB 테이블에 audit을 추가하면 좋다는 리뷰를 다른 크루의 리뷰에서 봤었는데, audit을 추가했을 때 관리 측면에서 좋은 이유가 무엇인가요? -> created_at, updated_at가 필요한 이유? 장애가 발생했을 때 롤백을 하기 위해서? 관리 측면도 있고, 게시판 형태에서 많이 사용한다. 차후에 미래를 생각하면서 만드는 것 같다. 예전에 만들어진 데이터에 관해서도
고칠 부분
- 404 응답을 5xx 예외로 변경하기