[TIL] 스프링 입문 - 테스트 코드와 Spring MVC
Spring 테스트 코드의 필요성과 블랙박스 테스트, 개발자 테스트 방식을 정리한 TIL입니다.
For the English version of this post, see here.
오늘 한 것
- Spring 입문
오늘 배운 것
테스트 코드
버그 bug 소프트웨어가 예상하지 못한 결과를 내는 것
개발 코드 배포 전, 버그를 찾아내는 법
- 블랙박스 테스팅 소프트웨어 내부 구조나 동작원리를 모르는 블랙박스와 같은 상태에서, 즉 웹 서비스의 사용자 입장에서 동작을 검사하는 방법 장점: 누구나 테스트 가능 단점: 기능이 증가될 수록 테스트의 범위가 증가, 테스트 하는 사람에 따라 테스트 퀄리티가 다를 수 있음
- 개발자 테스트 개발자 직접 본인이 작성한 코드를 검증하기 위해 테스트 코드를 작성함 장점: 빠르고 정확한 테스트 가능, 테스트 자동화 가능, 리팩토링이나 기능 추가 할 때 편리 단점: 개발 시간이 오래 걸림, 테스트 코드 유지보수 비용 발생
JUnit 자바 프로그래밍 언어 용 단위 테스트 프레임워크
이미 build.gradle에 추가돼있음 -> JUnit을 사용할 준비가 완료된 상태
- 테스트 파일 생성
Java는 반드시 main() 메서드로 시작해 main() 메서드로 끝난다고 배웠지만, JUnit은 테스트 실행 환경을 가지고 있기 때문에 사진처럼 따로 main() 메서드를 실행하거나 서버를 실행시키지 않아도 각각의 메서드 혹은 기능별로 테스트 코드를 작성하여 실행시킬 수 있다.
Lombok과 application.properties
Lombok 자바 프로젝트를 진행하는데 거의 필수적으로 필요한 메서드/생성자 등을 자동 생성해줌으로써 코드를 절약할 수 있도록 도와주는 라이브러리
@Getter, @Setter
Memo 자바 클래스 생성 | 직접 입력하지 않은 getUsername(), getContents() 메서드가 @Getter 어노테이션을 통해 자동으로 만들어져있는 것을 확인할 수 있음 (@Setter 또한 마찬가지) |
@AllArgsConstructor, @NoArgsConstructor 기본 생성자와 모든 필드를 파라미터로 가진 오버로딩된 생성자를 만들어 줌
@AllArgsConstructor로 오버로딩된 생성자를 만들게 되면- Java에서는 생성자가 하나라도 정의되면 기본 생성자를 자동 생성하지 않기 때문에 -> 따라서,
@NoArgsConstructor를 통해 기본 생성자를 만들어 줌 @RequiredArgsConstructor final 제어자가 붙은 필드를 파라미터로 가진 오버로딩된 생성자를 만들어 줌
application.properties Spring과 관련된 설정을 할 때 사용하는 파일
- src > main > resources > application.properties
- SpringBoot를 통해 자동으로 설정되고 있는 설정 값을 쉽게 수정할 수 있음
- DB 연결 시 DB의 정보를 제공해야하는데, 이러한 경우에도 이 파일 이용해 쉽게 값 전달 가
MySQL
터미널
- MySQL 접속
cd /usr/local/mysql/bin위치 이동./mysql -u root -pMySQL 접속 -> 비밀번호 입력
Spring MVC
MVC (Model-View-Controller) 소프트웨어 디자인 패턴 중 하나
- MVC 패턴: 소프트웨어를 구성하는 요소들을 Model, View, Controller로 구분하여 각각의 역할을 분리함
- 소프트웨어를 구성하는 요소들을 분리함으로써 코드의 재사용성과 유지보수성을 높이고, 개발자들 간의 협업을 용이하게 함
- Model
- 데이터와 비즈니스 로직을 담당함
- 데이터베이스와 연동하여 데이터를 저장하고 불러오는 등의 작업을 수행함
- View
- 사용자 인터페이스를 담당함
- 사용자가 보는 화면과 버튼, 폼 등을 디자인하고 구현함
- Controller
- Model과 View 사이의 상호작용을 조정하고 제어함
- 사용자의 입력을 받아 Model에 전달하고, Model의 결과를 바탕으로 View를 업데이트함
Spring MVC (Spring Web MVC) Servlet API를 기반으로 구축된 독창적인 웹 프레임워크
- 처음부터 Spring Framework에 포함되어 있음
- DispatcherServlet이 중앙에서 HTTP 요청을 처리해주는데 이는 Front Controller 패턴으로 설계되어있음 -> Spring에서 MVC 패턴을 적용해 HTTP 요청을 효율적으로 처리하고 있음
Servlet: 자바를 사용하여 웹 페이지를 동적으로 생성하는 서버 측 프로그램 혹은 그 사양
- 사용자가 Client(브라우저)를 통해 서버에 HTTP Request 즉, API 요청을 함
- 요청을 받은 Servlet 컨테이너는 HttpServletRequest, HttpServletResponse 객체를 생성함
- 약속된 HTTP의 규격을 맞추면서 쉽게 HTTP에 담긴 데이터를 사용하기 위한 객체
- 설정된 정보를 통해 어떠한 Servlet에 대한 요청인지 찾음
- 해당 Servlet에서 service 메서드를 호출한 뒤 브라우저의 요청 Method에 따라 doGet 혹은 doPost 등의 메서드를 호출함
- 호출한 메서드들의 결과를 그대로 반환하거나 동적 페이지를 생성한 뒤 HttpServletResponse 객체에 응답을 받아 Client(브라우저)에 반환함
- 응답이 완료되면 생성한 HttpServletRequest, HttpServletResponse 객체를 소멸함
Front Controller
- 모든 API 요청을 앞서 살펴본 서블릿의 동작 방식에 맞춰 코드를 구현한다면, 무수히 많은 Servlet 클래스를 구현해야함 -> 따라서, Spring은 DispatcherServlet을 사용해 Front Controller 패턴 방식으로 API 요청을 효율적으로 처리함
- Client(브라우저)에서 HTTP 요청이 들어오면 DispatcherServlet 객체가 요청을 분석함
- DispatcherServlet 객체는 분석한 데이터를 토대로 Handler mapping을 통해 Controller를 찾아 요청을 전달해 줌 Handler mapping: API path와 Controller 메서드가 매칭되어 있음 ex)
@GetMapping("/api/hello")GET /api/hello → HelloController 의 hello() 함수 GET /user/login → UserController 의 login() 함수 GET /user/signup → UserController 의 signup() 함수 POST /user/signup → UserController 의 registerUser() 함수
-> 직접 Servlet을 구현하지 않아도 DispatcherServlet에 의해 간편하게 HTTP 요청을 처리할 수 있게됨
- Controller -> DispatcherServlet
- 해당 Controller는 요청에 대한 처리를 완료 후 처리에 대한 결과 즉, 데이터(‘Model’)와 ‘View’ 정보를 전달함
- DispatcherServlet -> Client
- ViewResolver 통해 View에 Model을 적용하여 View를 Client에게 응답으로 전달함
내일 학습할 것
- Spring 입문 완강
- 알고리즘 2문제
- Spring 심화 수강




