TDD
- 테스트 주도 개발(Test-Driven Development)
- 프로그램 작성보다 테스트코드를 먼저 작성한다.
TDD의 목표
- 작동하는 깔끔한 코드(Clean code that works)
TDD의 원칙
- 자동화된 테스트가 실패한 경우만 새로운 코드를 작성한다.
- 중복을 제거한다.
- 실패하는 테스트를 작성하기 전에 코드를 작성하지 않는다.
- 실패하는 테스트 코드를 한번에 하나 이상 작성하지 않는다.
- 실패하는 테스트를 통과하기에 충분한 정도를 넘어서는 코드를 작성하지 않는다.
TDD의 장단점
- 장점
- 코드의 유지보수가 용이해진다.
- 소스코드의 기록이 된다.
- 프로그래밍 시간(프로그램 전체의 라이프 사이클)이 단축된다.
- 단점
- 프로그래밍 시간(코드를 만드는 시간)이 길어진다.
테스트의 종류
- 단위 테스트
- 소스코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 테스트
- F.I.R.S.T 원칙
- Fast: 단위 테스트는 빨라야 한다.
- Independent/Isolated: 독립적으로 수행되어야 한다.
- Repeatable: 반복적으로 수행해도 결과가 같아야 한다.
- Self Validating: 스스로 검증할 수 있어야 한다.
- Timely: 필요할 때 미루지 말고 적시에 작성되어야 한다.
- 통합 테스트
- 단위 테스트 이후 모듈들의 상호작용이 제대로 이루어지는지 검증하는 테스트
TDD 사이클
- 테스트를 추가한다.
- 모든 테스트를 실행하고 새로 추가한 것이 실패하는지 확인한다.
- 코드를 조금 변경한다.
- 모든 테스트를 실행하고 전부 성공하는지 확인한다.
- 리팩토링을 통해 중복을 제거한다.
Annotation
Mock
- 객체간 의존성이 있는 객체를 대신하는 가짜 객체
Mock 객체가 필요한 순간
- 테스트 작성을 위한 환경 구축이 어려운 경우
- 테스트가 특정 경우나 순간에 의존적인 경우
- 테스트 시간이 오래 걸리는 경우
- 서버나 PC의 성능문제로 오래 걸릴 수 있는 시간을 단축하기 위해 사용
@SpringBootTest
- 어플리케이션 레벨 테스트시 사용.
- 서버 프로그램의 환경설정, 포트, 주소 등 실행될때의 런타임 테스트
- 통합 테스트 수행시 적합
- 테스트 실행시 서버 어플리케이션이 실행됨
- 실제 구동되는 어플레이션과 똑같은 Application Context를 로드함
- 어플리케이션이 로드되기 때문에 어플리케이션이 커질경우 속도가 느려짐
@WebMvcTest
- MVC를 위한 테스트
- 대표적으로 Controller 테스트를 할 때 사용
- Request, Response를 테스트 할 수 있는 어노테이션
- Spring Security가 제공하는 로그인, 로그아웃, 세션, 필터도 자동으로 테스트 가능
- @SpringBootTest 어노테이션을 이용해도 @WebMvcTest에서 가능한 테스트는 모두 가능하지만 MVC관련 어노테이션(@Controller, @ControllerAdvice, JsonComponent)과 Filter, WebConfigurer, HandlerMethodArgumentResolve만 로드하기 때문에 가볍다.
@DataJpaTest
- JPA관련 테스트 설정만을 로드함
- DataSource의 설정 유효성, 정상 여부, DDL, DML의 정상 수행 여부 등의 테스트가 가능
@RestClientTest
- 클라이언트 요청을 서버가 정상적으로 수행하는지를 검증하기 위한 테스트
@JsonTest
댓글남기기