일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 |
- 소프티어
- 프로그래머스
- 회고
- 공부일지
- BFS
- 데이터베이스
- 알고리즘
- SQL
- 자바
- 백준
- 백준 알고리즘
- 시나공
- 백준알고리즘
- programmers
- SW봉사
- java
- python
- CJ UNIT
- 파이썬
- 정보처리산업기사
- 코딩봉사
- 코틀린
- 1과목
- kotlin
- 스프링
- softeer
- C++
- 코딩교육봉사
- MYSQL
- 문제풀이
- Today
- Total
JIE0025
[테스트코드] 테스트코드 작성의 기본 본문
✅ TDD
TDD (Test-Driven Development)
: 테스트가 주도하는 개발
테스트 코드를 먼저 작성한 후,
구현 코드 작성 단계와 리팩토링 단계를 짧은 주기로 반복하여 개발하는 '
테스트 주도 개발 방법론'
- RED : 항상 실패하는 테스트를 먼저 작성
- GREEN : 테스트가 통과하는 프로덕션 코드를 작성
- REFACTOR : 테스트가 통과하면 프로덕션 코드를 리팩토링 (불필요한 코드제거)
✅ 단위테스트 (Unit Testing)
TDD 는 단위테스트가 아니다!
TDD의 첫 번째 단계 인 기능 단위의 테스트 코드를 작성하는 것을 이야기함.
⏺ 테스트 코드는 왜 작성해야할까?
✔️ 위키피디아..
- 단위 테스트는 개발단계 초기에 문제를 발견하게 도와준다.
- 단위 테스트는 개발자가 나중에 코드를 리펙토링하거나 라이브러리 업그레이드 등에 서 기존 기능이 올바르게 작동하는지 확인할 수 있다. (예. 회귀 테스트).
- 단위 테스트는 기능에 대한 불확실성을 감소시킬 수 있다.
- 단위 테스트는 시스템에 대한 실제 문서를 제공한다. 즉, 단위 테스트 자체가 문서로 사용될 수 있다.
결론은!
- 테스트코드를 작성하면, 더이상 사람이 눈으로 검증하지 않고, 자동검증이 가능하다.
- 개발자가 만든 기능이 안전하게 보호된다. 새로운 기능을 추가했는데 기존의 A기능이 문제가 생긴것을 발견하게 되면?
- 테스트코드는 기존 기능이 잘 작동되는것을 보장해준다.
우리는 Java- Junit을 사용할 것이다!
스프링 부트와 AWS로 혼자 구현하는 웹서비스의 코드를 작성해보면서 본 관련 어노테이션을 추가한다.
1. controller
@RestController
Json을 반환하는 컨트롤러로 만들어줌
@GetMapping("/hello")
HTTP Get 요청 받을 수 있는 API를 만들어줌 /hello 요청이들어오면 URI매핑
@RequestParam("amount") int amount
외부로부터 받아온 name이라는 이름으로 받은 값을 메소드 파라미터 String name에 저장함
2. DTO
Lombok Annotation
@Getter
getter를 만들어줌
@RequiredArgsConstructor
선언된 모든 final 필드가 포함된 생성자를 생성해줌
(단 final이 없는 필드는 생성자에 포함되지 않음)
3. Testing
@RunWith(SpringRunner.class)
- Junit4에서 사용
- @SpringBootTest는 application context를 전부 로딩 > 무거운 프로젝트의 역할이 될 수 있음
- RunWith은 @Autowired, @MockBean에 해당되는 것들에만 application context 로딩함.
@WebMvcTest(controllers = HelloController.class)
web(MVC)에 집중하는 어노테이션
- 가능 : @controller, @ControllerAdvice
- 불가능 : @service, @component, @repository
mockMvc.perform(get("/hello"))
.andExpect(status().isOk())
.andExpect(content().string(hello));
mockMvc.perform(
get("/hello/dto")
.param("name", name) // ①
.param("amount", String.valueOf(amount)))
.andExpect(status().isOk())
.andExpect(jsonPath("$.name", is(name)))
.andExpect(jsonPath("$.amount", is(amount)));
}
- 메서드 체이닝 지원
- perform(get("/hello/dto"))
- 해당 주소로 get 요청
- .param("name", name)
- key- value 파라미터 전달 (String만)
- andExpect()
- 응답 결과 객체 (ResultAction)리턴
- status().isOk()
- perform의 결과 검증 - http header의 상태코드 검증 > 200인가?
- jsonPath("$.name", is(name))
- Json 응답 값을 필드별로 검증할 수 있는 메소드
- $기준으로 필드명 명시
- content().string(hello)
- result body data가 hello와 같은 값인지
'백엔드 부트캠프 > +' 카테고리의 다른 글
[+] Controller 구현 실습 (0) | 2022.12.15 |
---|---|
[질문에 답하기] @Configuration annoted & BeanDefinition 관련 (0) | 2022.12.15 |
[객체지향] SOLID 원칙 (0) | 2022.12.06 |
[+Schema] UPDATE /Desinging Schema Instagram/ (0) | 2022.12.03 |
[+Schema] Desinging Schema Instagram (0) | 2022.12.03 |