Test case
입문 강의 때와 같이 기능별로 클래스를 구분하여 코드를 작성해준다. (이 부분은 그냥 많이 해보면서 익숙해져야 할 것 같다. 역할의 분리와 java 문법 이해가 필요로 한 것이므로 굳이 정리를 하지 않겠다.) 각 기능들이 오류가 없이 작성되었는지 확인해주어야 한다. 어플리케이션 전체를 만들고 한 번에 실행 후 오류를 찾는 건? 해보지 않았지만 벌써 끔찍하다. 기능별로 테스트 케이스를 세분화하여 작성하는 게 좋다고 한다. junit 프레임워크를 사용한다.
@Test
@DisplayName("vip는 10% 할인이 적용되어야 한다.")
void vip_o() {
//given
Member member = new Member(1L, "memberVip", Grade.VIP);
//when
int discount = discountPolicy.discount(member, 10000);
//then
Assertions.assertThat(discount).isEqualTo(1000 );
}
@Test 어노테이션을 붙여주면 스프링이 테스트 케이스인것을 인지한다. @DisplayName은 테스트 케이스가 많아지면 함수명만을 보고서 이 테스트가 어떤 경우였는지 알아보기 힘들 수 있다. 그럴 때 사용하면 다음 사진과 같이 표시된다.
이렇게 작성하면 테스트 케이스가 많아도 무엇에 관련된 테스트였는지 알아보기 쉬울 것이다. 여기서 다음 내용의 힌트가 있다. 할인 관련 테스트를 두번 작성한 것을 알 수 있다.
테스트 케이스는 반대의 경우도 작성을 해줘야 한다. 위와 같이 할인이 적용되는 경우, 안되는 경우 또는 성공하는 경우, 실패하는 경우와 같이 정반대의 케이스를 모두 확인해주는 것이 이상적인 테스트 방법이다. (위에 코드에서는 vip_x() 메소드를 작성해주면 된다.)
각 메소드안에서 코드를 작성할 때 //given //when //then을 사용하면 작성 중에 혼돈도 줄이고 나중에 볼 때도 이해하기 간편하다.
//given ==> 이런 옵션이 주어졌고 //when ==> 이런 이벤트를 적용했을 때 //then ==> 이 예상 값이 나와야 한다! 정도로 생각하면 되겠다.
'Spring' 카테고리의 다른 글
[Spring] 스프링 컨테이너 & 스프링 빈 조회 (3) | 2022.07.20 |
---|---|
[Spring] AppConfig (0) | 2022.07.16 |
[Spring] 객체지향 기본 개념 (0) | 2022.07.12 |
[Spring] 동적 페이지 만들기 (1) | 2022.02.06 |
[Spring] welcome page, 정적 페이지 만들기 (1) | 2022.02.06 |