소프트웨어 공학 쇼핑몰 만들기
소프트웨어 공학 수업의 과제로 웹 쇼핑몰을 만드는 과제가 주어졌는데, 나의 경우 스프링부트와 JPA를 사용하여 백엔드단 서버를 만들고자 했다.
그런데, 단순히 뚝딱 만들어내는게 아니라 고려해야할 점이 생각보다 많았다..
개선할 사항을 적어내려 가면서 코드가 어떻게 바뀌어 가는지, 왜 그렇게 바꾸었는지를 확인하고자 한다.
1. 테스트
- 학교 과제나 토이 프로젝트를 할 때는 테스트 코드를 따로 작성하지 않았는데, 최근 인프런을 보면서 공부하는 중에 테스트 코드를 자주 작성하여 검증하는걸 볼 수 있었다. 테스트의 장점은 인터넷에 찾아보면 널리고 널렸지만, 정작 꼼꼼하게 작성하는 사람들은 몇 없을 거라고 생각하여 크게 와닿지는 않았지만 스프링 환경에서 테스트를 지원하는 방식이 다양하고 케이스별로 자세하게 돌릴 수 있어서 이 기회에 같이 작성해보고자 한다.
- 테스트를 먼저 작성하고 개발을 진행하는 TDD 방식도 있다는걸 알았다.
- 그런데 테스트 코드를 작성하다 보니 개발 코드보다 검증하는 코드가 더 많은 것 같다.. ㅎㅎ;; 아직 부족해서 그런건가
1.1 스프링부트의 테스트 방법
- 간단하게 Assertion.assertEqual로 진행할 수 있지만, 계층으로 아키텍처를 구분하는 스프링에서는 각 계층마다 테스트 방식을 달리하여 응집력을 높이는 방식이 주로 사용된다.
- 오늘까지 개발한 내용들은 Repository와 Service 레이어들의 테스트 코드를 작성했다.
- Service의 테스트 방식은 도메인 모델들의 순서가 보장되는 지, 레포지토리의 함수가 호출되는지 등을 검증한다.
- Repository의 테스트 방식은 @Transactional 애노테이션을 붙여 테스트가 끝난 뒤에는 모두 지우도록 하고, 레포지토리 빈을 주입받아 테스트한다.
2. RESTful하게 만들기
데이터베이스 수업에서는 장고로 간단한 수강신청 웹 애플리케이션을 만들었는데, 요청에 따른 응답을 서버사이드 렌더링 방식으로만 했었기 때문에 따로 HTTP에 신경을 쓸 겨를이 없었다.
그런데, 이번에는 프론트, 백을 나누어서 작업하기 때문에 RESTful의 의미에 대해 공부하면서 어떤 점들을 고려해야 하는지 고민하게 되었다.
(처음에 든 생각은 백엔드라고 해봐야 문자열만 리턴하면 되는거 아냐? 라고 생각했었는데, 그게 아니더라.. ㅎㅎ;;)
예시로 내가 작성한 코드를 보면서 어떻게 개선해야 할지 문제점을 짚어보자.
@PutMapping("/{id}")
public Long update(@PathVariable Long id, GoodsDto updateDto)
{
return goodsService.updateById(id, updateDto);
}
id 값에 따라 업데이트하며, 응답으로 단순히 정수 값을 리턴하는 로직이다. 그런데 위 코드는 HTTP 상태 응답코드와 메시지를 넣을 수 없다.
★개선할 점
만약 id 값이 DB에 없다는 상황에서 호출해도 200 OK 응답코드를 받는다. 하지만 이런 방식은 상태 응답 코드의 의미와 맞지 않다. 그래서 ResponseEntity 라는 미리 만들어진 클래스를 이용하여 메시지와 상태 응답 코드를 같이 보낼 수 있도록 한다.
또한 HTTP의 헤더에는 다양한 정보들이 포함될 수 있는데, Client에서 이러한 헤더들로 다르게 구분하여 보여줄 수 있기 때문에 고려해야 한다.
- 스프링부트에서 파일처리
- 스웨거 적용 방법
- jpa에서 fetch 타입과 고아 객체 처리 방법, 복합키 처리 (Embeddable, IdClass)방법
- 개선점) 컨트롤러 단에서의 테스트 방법과 입력값 검증
- 개선점) 테스트 커버리지
- 개선점) 업로드 이미지, 파일 처리 방법
- 개선점) 배포 방식
- 개선점) 리다이렉트 적용