들어가기 앞서
스터디 영상
스터디 자료
안녕하세요~! 백엔드 파트리드 권찬입니다 
이번 스터디에서는 어플리케이션의 비즈니스 로직을 실제로 풀어내는 서비스 계층과 클라이언트의 요청을 받아들이고, 데이터를 응답하는 컨트롤러 계층을 작성하였습니다.
이번 스터디에서는 어플리케이션의 비즈니스 로직을 실제로 풀어내는 서비스 계층과 클라이언트의 요청을 받아들이고, 데이터를 응답하는 컨트롤러 계층을 작성하였습니다.이로써 드디어 스프링을 사용한 웹 어플리케이션을 완성했습니다!!
스프링이라는 낯설고 복잡한 도구를 공부하는 과정이 분명 쉽지 않으셨을 텐데 여기까지 따라 오시느라 정말 수고 많으셨습니다.
스프링이라는 낯설고 복잡한 도구를 공부하는 과정이 분명 쉽지 않으셨을 텐데 여기까지 따라 오시느라 정말 수고 많으셨습니다. 이번 주 과제는 1주차 과제로 직접 작성하셨던 API 명세서를 참고하셔서 모든 도메인(엔티티)의 서비스, 컨트롤러 계층을 완성하는 것이 과제입니다.
(1주차 때 API 명세서와 달라져도 괜찮습니다!)
더 공부해보면 좋을 내용
혹시 컨트롤러 계층을 더 깊고 자세하게 공부해보고 싶으시다면 인프런에서 김영한 강사님의 스프링 MVC 강의를 수강해보시길 추천드립니다.
이번 스터디에서는 6주라는 시간 관계상 서비스 코드의 로직을 검증하는 테스트 코드를 작성하지 못했는데요
지난 학기 백엔드 스터디에서는 서비스 계층에 대한 단위 테스트를 작성하는 내용도 다루었으니 관심있으시면 영상을 시청해보셔도 좋을 것 같습니다.
그 밖에도 컨트롤러 계층을 단독으로 테스트하여 특정 에러가 발생했을 때 특정 상태 코드와 에러메세지가 담긴 응답이 잘 발생하는지, 에러가 없을 때는 특정 상태 코드와 데이터가 담긴 응답이 잘 발생하는지 테스트하고 싶다면 MockMvc 를 사용한 테스트를 찾아보시길 추천드립니다.
또 컨트롤러 계층을 포함해서 모든 로직에 대한 통합 테스트를 스프링 부트를 올려서 테스트하는 코드로 작성해보고 싶으시다면 RestAssured 라는 라이브러리를 공부해보시길 추천드립니다.
과제
목표
•
서비스, 컨트롤러 계층 작성
•
포스트맨을 활용한 API 테스트
제출해야할 파일과 파일 경로
1.
week5 폴더에 wil.md 를 작성해주세요.
2.
서비스, 컨트롤러 계층 작성 (폴더 구조 예시 참고)
3.
포스트맨 API 테스트
폴더 예시
week5/
└── wil.md
└── 포스트맨 테스트 성공/실패 스크린샷
todoapi/
└── main/
└──── java/
└────── com.example.todoapi/
└──────── todo/
└────────── dto/
└──────────── TodoCreateRequest.java
└──────────── TodoUpdateRequest.java
└──────────── TodoResponse.java
└────────── Todo.java
└────────── TodoRepository.java
└────────── TodoService.java
└────────── TodoController.java
└──────── member/
└────────── Member.java
└────────── MemberRepository.java
└────────── MemberService.java
└────────── MemberController.java
└────── ...
YAML
복사
과제 설명
•
API 요청을 보낼 때 어떤 형식의 데이터를 보내고, 어떤 형식으로 데이터를 돌려줄 지는 자유롭게 정하셔서 만들어주세요.
단, 로그인의 경우 로그인에 성공하면 서버는 클라이언트에게 로그인에 성공한 유저를 식별할 수 있는 데이터를 제공해주어야 합니다.
이 데이터는 간단하게는 pk 를 제공해주셔도 좋고, 더 깊게 들어가면 세션 ID나 토큰이 될 수도 있습니다. 자세한 내용은 ‘스프링 인증’, ‘스프링 로그인 구현’ 과 같은 키워드로 검색해보시면 정보가 많이 나올거에요
프론트 입장에서는 로그인에 성공했을 때 서버가 알려준 유저 식별값을 활용해서 나의 할 일 조회, 생성, 수정, 삭제 요청을 보낼 수 있습니다.
•
서비스 계층을 구현하실 때 프로젝트 명세에 없는 부분은 자유롭게 정책을 정해서 구현해주시면 됩니다.
예를 들어 비밀번호에 특수기호가 포함되어야 하고, 길이가 8글자 이상이어야 한다면, 멤버 데이터를 저장하기 전에 프론트가 보내준 데이터가 형식에 맞는지 검사를 하고 적절한 예외를 발생시킬 수 있습니다. (다음 주 스터디에서 DTO 클래스에 유효성 검사를 추가하면서 이와 관련하여 간단하게 처리하는 방법도 알아봅니다)
또 스터디에서 구현하지 않았던 할 일 수정, 삭제 전에 이 할 일을 수정, 삭제하려는 유저가 그 할 일을 만든 유저인지 검사 해보셔도 좋습니다.
•
컨트롤러 계층을 구현하실 때는 DTO 클래스와 엔티티 클래스 간 변환에 대해서도 고민해보시고 찾아보시는 것도 추천드립니다.
(엔티티 → 응답 DTO / 요청 DTO → 엔티티)
또 폴더 구조 예시에서는 스터디와 다르게 DTO 클래스를 dto 라는 패키지로 묶어두었는데요, 스터디 영상에서 한 것처럼 같은 패키지에 두셔도 상관없으니 편하신 구조로 만들어주시면 됩니다!
•
API 를 완성하셨다면 포스트맨으로 잘 동작하는지 테스트하고, 일부 API 에 대한 테스트 결과를 스크린샷으로 찍어주세요. 어떤 데이터를 담아서 어떤 URL 로 요청을 보냈고, 그 응답은 어떻게 나는지 찍어주시면 됩니다!
테스트 결과는 성공한 것 하나와 실패한 것 하나씩 골라서 찍어주세요.
실패의 경우 구현 중 오류에 의한 실패가 아니라, 비즈니스 로직에 의해 의도적으로 실패한 경우를 테스트하고 올려주세요. (존재하지 않는 멤버로 요청, 로그인 실패, 다른 유저의 할 일 조작, 친구가 아닌 유저의 할 일 조회 등)
마감 기한
5/28 수요일 23:59 까지 제출해주세요.
자신의 레포지토리에 week5 폴더를 생성해 wil.md 파일을 제출합니다.
더 자세한 사항은 아래 링크를 참조해주세요.