- test Driven Development
프로덕션 코드보다 테스트 코드를 먼저 작성하여 테스트가 구현 과정을 주도하도록 하는 방법론
1단계 : Red
//TDD 1단계 : RED
@Test
void test(){
//요구사항잉 반영된 test 구문 작성
assertThat(tatalPrice).isEqualTo(8500);
}
2단계 : GREEN
public int calculateTotalPrice() {
return 8500;
}
3단계 : REFACTOR
//3단계 : 리팩토링 (여러번도 가능)
public int calculateTotalPrice() {
return beverages.stream()
.mapToInt(Beverage::getPrice).sum()
};
선 기능 구현 후 테스트 작성
- 테스트 자체의 누락 가능성
- 특정 테스트 케이스만 검증할 가능 (해피 케이스)
- 잘못된 구현을 다소 늦게 발견할 가능성
선 테스트 작성 , 후 기능 구현
- 복잡도가 낮은, 테스트 가능한 코드로 구현 할 수 있게 한다. (유연하며 유지보수가 쉬운)
- 쉽게 발견하기 어려운 엣지 케이스를 놓치지 않는다
- 구현에 대한 빠른 피드백을 받을 수 있다.
- 과감한 리팩토링이 가능해진다.
참고 및 출처 : https://www.inflearn.com/course/practical-testing-실용적인-테스트-가이드/dashboard
'TDD' 카테고리의 다른 글
Presentation Layer의 테스트 (0) | 2024.11.24 |
---|---|
레이어드 아키텍처(Layered Architecture) 와 테스트 (0) | 2024.11.18 |
테스트는 [문서]다 (1) | 2024.11.15 |
단위테스트(Unit test) (1) | 2024.11.10 |
테스트는 왜 필요할까? (0) | 2024.11.09 |