TDD

프로그램 작성보다 테스트 코드를 먼저 작상한다.

TDD의 목표 => 작동하는 Clean Code를 만드는게 목표

TDD 원칙

• 자동화된 테스트가 실패한 경우만 새로운 코드를 작성한다. (대원칙) – 잘동작중인 코드를 변경하지 말라
• 중복을 제거한다. (대원칙) – 리팩토링
• 실패하는 테스트를 작성하기 전엔 코드를 작성 하지 않음 (대원칙을 지키기위한) – 테스트 코드를 먼저 작성한다.
• 실패하는 테스트 코드를 한번에 하나 이상 작성하지 않는다.(대원칙을 지키기위한) 
• 실패하는 테스트를 통과하기에 충분한 정도를 넘는 코드를 작성하지 않는다. (대원칙을 지키기위한)  – 열을 알지 말자 

TDD의 개발 발식 

테스트 코드 -> 본 코드 작성 -> 리펙토링

TDD의 장점

• 유지 보수가 용이
• 소스코드의 기록이 된다.
• 테스트 코드가 항상 작성되니 유지보수시 수정하는 시간이 줄어든다. 

TDD의 단점

• 특정 구현을 구현하는 시간이 오래걸린다. 

테스트 종류 

• 단위 테스트 
  • 소스코드의 특정 모듈이 의도된 대로 작동하는지 검증하는 테스트
  • FIRST 원칙을 지켜라 
    • Fast – 빨라야함
    • Independent/ Isolated – 독립적이어야함
    • Repeatable – 반복할 수 있어야  함
    • Self Validating – 스스로 검증이 가능 해야함
    • Timely – 적시에 해야함
• 통합테스트 
  • 단위 테스트 이후 모듈들의 상호작용이 제대로 이루어 지는지 검증하는 테스트

TDD 적용

저장고를 만든다고 가정해보자 

속성

• 가로, 세로, 높이
• 냉장, 냉동, 일반
• 총 저장 수량
• 현재 수량

To-Do

전체적인 것이아닌 세세한 것부터 출발

• 저장고의 크기
• 저장의 타입
• 저장 가능한 수량
• 현제 저장된 수량

Spring Test

테스트 관련 Spring 공식 문서 

https://docs.spring.io/spring-framework/docs/current/reference/html/testing.html#testing-introduction

Mock

객체간 의존성이 있는 객체를 대신하는 가짜 객체 

• 테스트 작성을 위한 환경 구축이 어려운 경우
• 테스트가 특정 경우나 순간에 의존적인 경우

@SpringBootTest

• 통합테스트 애노테이션
• APP 전체를 로드
• 같은 Application Context를 로드함 => Fast Context등 다른 Context를 로드할  수 도 있음 

@WebMvcTest

• Controller 테스트
• Request, Response를 테스트할  수 있는 애노테이션 
• Spring Security 가 제공하는 로그인, 로그아웃, 세션, 필터 도 자동 테스트 가능 
• @Controller, @ControllerAdvice, @JsonComponent, Filter, WebConfigurer, HandlerMethodArgumentResolver 만 로드하여 비교적 가벼운 유닛 테스트

@DataJpaTest

• JPA 관련 테스트 설정만을 로드함 
• DataSource의 설정 유효성, 정상 여부 , DDL, DML 등여부도 테스트 가능

@RestClientTest

• 클라이언트 요청을 서버가 정상적으로 수행하는지를 검증하는 테스트

@JsonTest

• Json 직렬화 역직렬화 테스트

From.

Fast Campus

블로그 구독하기 !!