사진은 학교 도착한 첫 주에 찍은 밤 하늘 - 친구랑 길바닥에 누워서 별 많이 보인다고 신기해하면서 별사진 열심히 찍었다. 북두칠성도 보였던 것 같은데
제일 어려운 섹션이었다... 블로깅도 한번하고 끝나버린... 섹션 끝났으니까 한번 더 다시 실습하고 복습하면서 익혀야겠다. 기술 면접은 최대한 말하는 정보 늘렸는데도 시간이 처참하게 나와서 걱정이다. 어떻게 30분 채우지?
DTO = Data Transfer Object
🔹 데이터를 전송하기 위한 용도의 애플리케이션 아키텍처 패턴 중 하나
🔹 클라이언트에서 서버쪽으로 전송하는 요청 데이터, 서버에서 클라이언트 쪽으로 전송하는 응답 데이터~ > 이 구간에서 DTO 사용
🔹 클라이언트로부터 요청데이터를 받을때 DTO사용 안하면 핸들러 메서드에서 @RequestParam 을 파라미터로 다 받아야됨
(email, name, phone 다 애너테이션 붙여서 받아야되어서 코드 복잡해짐) => 이 요청 데이터를 하나의 객체로 전달받는게 DTO 클래스: 요청 데이터를 하나의 객체로 전달받는 역할
리팩토링 방법:
DTO 클래스 생성
-> @RequestParam으로 요청 데이터 전달받는 핸들러 메서드 찾아서 이 @RequestParam 쪽 코드들을 DTO클래스의 객체로 수정
-> Map 객체로 작성되어있는 Response Body 를 DTO클래스 객체로 변경
이때 DTO클래스에 각 멤버변수에 해당하는 getter 꼭 있어야함
🔹 DTO 클래스를 사용하면 유효성 검증 로직을 DTO 클래스로 빼내서 핸들러 메서드를 간결하게 유지할 수 있음
🔹 전체적으로 코드 간결해짐
But,
🔹 Controller 클래스별로 DTO클래스 추가적으로 작성해야됨.
🔹 Controller 클래스 늘어남에 따라 DTO클래스가 두배로 늘어남 (클래스 내에 핸들러 메서드만큼)
테스트: 실제 코드로 도출되는 값이 기대값과 같은지 확인하고 비교
기능 테스트:
🔹가장 범위가 큰 테스트
🔹애플리케이션을 사용하는 사용자 입장에서 애플리케이션이 제공하는 기능이 올바르게 동작하는지를 테스트
🔹주로 개발자보다는 QA부서 or 외부 QA업체가 함
🔹API툴, DB연관되어있어서 얽혀있는게 많다
통합 테스트:
🔹보통 개발자나 개발팀이 함
🔹주로 클라이언트 측 툴 없이 개발자가 짜둔 테스트 코드 실행
🔹e.g. Controller API 호출하는 테스트코드 작성하고 실행하면 서비스 계층과 데이터 액세스 계층 거쳐서 DB에 실제로 접속하여 기대했던 동작을 하는지 확인
🔹But, 여러계층 연관, DB까지 연결되어있어 독립적인 테스트가 아니므로 단위테스트라고 하기 어려움
슬라이스 테스트:
🔹애플리케이션을 특정 계층으로 나누어 테스트
🔹But, 해당 계층에서 HTTP 요청 필요하고, 외부 서비스 연동되기도 하고 특히 데이터 액세스 계층은 DB연동하므로 단위테스트 ❌
🔹애플리케이션 일부만 테스트해서 '부분 통합 테스트'라고도 부름
단위 테스트:
🔹비즈니스 로직에서 사용하는 클래스들이 독립적으로 테스트하기 제일 좋아서 보통 단위 테스트라고 부름
🔹대부분 메서드 단위로 단위 테스트 코드 작성
🔹최대한 독립적이고 작은 단위일수록 좋음 -> 테스트 코드 짜기 더 단순, 빨라짐
🔹 build나 bootJar 태스크 실행하면 실행 가능한 .jar파일이 생성됨
🔹 이 때 profile은 이 실행 파일에 대한 실행 환경을 쉽게 지정할 수 있게 도와줌
🔹 예를 들어, 보통 로컬 환경에서는 h2 같은 인메모리 DB를 사용하지만, 서버 환경에 배포한다면 서버에서 사용하는 DB가 따로 있음
🔹 application.yml
파일에는 이런 정보가 포함되어있는데, profile을 사용하면 하나의 application.yml 파일이 아니라, application-local.yml
, application-server.yml
과 같이 환경에 따른 DB정보를 다르게 저장할 수 있음.
🔹 IntelliJ 기준으로 설명하자면, 실행파일의 환경설정에서 Program arguments 에 프로파일을 추가할 수 있음.