- 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::..

작은 코드 단위로 독립적으로 검증하는 테스트 (클래스 or 메서드)검증 속도가 빠르고, 안정적이다. 예시로 음료 여러 잔을 한번에 담는 기능을 단위테스트 해보자기능을 구현 할 때는 아직 드러나지 않은 요구 사항이 있는가 항상 고민해야한다 테스트 케이스 세분화하기1. 해피케이스 : 성공하는 케이스  cafeKiosk.add(americano,2); //해피케이스 assertThat(cafeKiosk.getBeverages().get(0)).isEqualTo(americano); assertThat(cafeKiosk.getBeverages().get(1)).isEqualTo(americano); 2. 예외케이스 : 실패하는 케이스 //예외 케이스assertThatThrownBy(()-> cafeK..

여기 기능을 가진 Production code가 있다. Production code는 계속해서 요구사항을 반영해서 기능을 확장해 나간다.만약 Production code를 사람이 계속 테스트 한다면?Production code 확장하는 만큼, 기존의 코드도 또 테스트 하게 되며, 커버 할 수 없는 영역 발생 하게된다.코드가 확장됨에 따라, 경험과 감에 의존하게 된다.시간이 오래걸리니 늦은 피드백을 받게 된다.유지보수가 어려워진다.결국 소프트웨어의 신뢰도가 하락하게 된다.   테스트 코드를 작성하지 않는다면? 변화가 생기는 매 순간마다 발생할 수 있는 모든 case를 고려해야 한다.변화가 생기는 매 순간마다 모든 팀원이 동일한 고민을 해야한다.빠르게 변화하는 소프트웨어 안정성을 보장할 수 없다. 아무렇게나..