참고:
1. 왜 Test 코드를 작성하는가?
•
Test 코드를 작성하지 않고 결과를 검증하는 과정은 비용이 많이 발생한다.
◦
Test 코드 사용 X
▪
검증 코드 작성
▪
애플리케이션 실행
▪
PostMan 혹은 브라우저 Request 요청
▪
log 혹은 print로 결과 검증
▪
원하지 않는 결과 발생 시 애플리케이션 종료
▪
다시 코드 작성
⇒ 위와 같은 로테이션이 계속 반복되며 간단한 애플리케이션을 실행하고 종료하는 과정에서 많은 비용이 발생한다.
◦
Test 코드 사용
▪
Test 코드 작성
▪
Test 코드 실행
▪
결과 검증
▪
Test 코드 수정
⇒ 애플리케이션을 실행, 종료할 필요가 없다. 따라서 비용이 줄어들고, Test 코드를 통한 명확한 결과 검증이 가능하다.
•
스프링의 계층 구조
◦
Controller : 클라이언트 요청을 받고 클라이언트에게 결과를 반환 (Presentation Layer)
◦
Service : 비즈니스 로직을 실행하고 결과를 반환 (Service Layer)
◦
Repository : database에 쿼리를 이용해서 CRUD를 하는 계층 (Data Access Layer)
◦
Domain : Entity 클래스
2. Springboot Test
•
Spring Initializer 를 통해 프로젝트를 생성하면 spring-boot-starter-test dependency 가 자동으로 추가된다.
이것을 이용하여 Test 코드를 작성하면 된다.
•
spring-boot-test-starter 구성요소
◦
spring-boot-test : 테스트에 필요한 핵심 기능 라이브러리
◦
spring-boot-test-autoconfigure: 테스트 진행 위한 Configuration 라이브러리
•
JUnit이란?
◦
Java에서 독립된 단위 테스트를 지원해주는 프레임워크
◦
Assert(검증)을 이용하여 결과를 기댓값과 실제값을 비교
◦
@Test 어노테이션마다 독립적으로 테스트가 진행
•
단위 테스트와 통합 테스트
◦
단위(unit) 테스트
▪
하나의 모듈을 기준으로 독립적으로 진행되는 가장 작은 단위 테스트 → 쉽게 말해 하나의 기능 혹은 메서드
◦
통합(integration) 테스트
▪
모듈을 통합하는 과정에서 모듈 간의 호환성을 확인하는 테스트
→ unit이 하나였다면 반대로 여러 개의 계층이 테스트에 참여한 것이라고 생각하면 쉬움
•
단위 테스트 장단점
◦
장점
▪
새로운 기능에 대해서 빠르게 작성 가능
▪
Test 코드 자체가 하나의 문서
▪
시간과 비용의 절감
◦
단점
▪
독립적인 테스트이므로 다른 객체와 상호작용 처리를 위해 가짜 객체애 대한 정의가 필요함
▪
가짜 객체의 답변 작성 필요함
▪
실제 운영 환경과 다른 답변을 내놓을 수 있는 가능성이 존재함
•
통합 테스트 장단점
◦
장점
▪
실제 객체를 사용하므로 가짜 객체를 사용하지 않아 정의할 필요가 없음
▪
실제 운영 환경과 같은 값을 도출할 수 있음
◦
단점
▪
하나의 테스트에 많은 비용이 들어감
▪
어느 계층에서 발생한 문제인지 파악하기가 어려움
•
단위 테스트냐 통합 테스트냐
단위 테스트, 통합 테스트 모두 장단점이 명확하다. 하지만 통합 테스트의 경우 비용을 절감할 수 있는 방법이 없다.
단위 테스트는 단점들을 개선해 나갈 수 있다.
•
좋은 단위 테스트란
◦
1개의 테스트는 1개의 기능에 대해서만 테스트
◦
테스트 주체와 협력자를 구분하기
▪
여기서 주체는 테스트를 할 객체
▪
협력자는 테스트를 진행하기 위해 정의하는 가짜 객체
◦
Given, when, then으로 명확하게 작성하기
▪
Given : 테스트를 진행할 행위를 위한 사전 준비
▪
When : 테스트를 진행할 행위
▪
then : 테스트를 진행한 행위에 대한 결과 검증