testing의 전략을 수립하자.

JUNIT 5는 무엇일까? 

 

일단 특징이 있다. 

전역변수로 COUNT를 선언하고, 

TEST1 ,TEST2에서 COUNT를 키워도값의 증가도 이루어지지않고, 주소 또한 다르게 나온다.

 

STATIC 변수로 COUNT를 선언하면, 값의 증가가 이루어지지만

주소는 다르게 나온다. *허나, 주의해서 사용하자. 

 

이 의미는 곧, 테스트코드의 실행시마다 인스턴스가 만들어진다는 뜻이다. 

<그 이유는, 이전 테스트의 사항이 이후 테스트에 변경되지 않게끔 하기 위함이다> 

 

@BERFORE ALL -> 테스트 실행전 한번 실행

@BERFOREEACH -> 모든 테스트의 실행 전 마다 실행된다

@AFTEREACH-> 모든 테스트마다 실행된 후 실행된다

@AFTERALL -> 테스트 실행 후 한번 실행된다. 

 

 

--다양한 파라미터를 편리하게 test할 수 있다. 

@ParameterizedTest

@ValueSource({원하는 값들의 배열} ) 이후, value로 받아 test가 가능하다. 

-같은 맥락의 @EnumSource도 사용이 가능하다. 

-csvsource와 같이, 다양한 source들이 존재한다. 

 

AssertJ 

강력한 검증이 가능하다.

어썰트j의 개발 전에는, assertThat을 사용했으나 assertj는 자동완성 기능이 어느정도 지원이 된다. 

 

주로 then(title).isblank ~~~로 와 같은 형식으로 검사를 진행한다. 

thenThrownby로, exception을 발생시킬 수도 있다.

 

테스트 전략

 

테스트 전략을 설게한 후에 테스트 코드를 작성하는 것이 굉장히 유리하다 .주로 4가지로

 

- 통합 테스트- 단위,jpa 테스트- 단위, mock 테스트 - 도메인 test가 있다.

 

단위, jpa test부터 보자 .

 

-web관련에 대해서 사용하지 않고, jpa에 관련된 test를 진행한다. 

 

1.DataJpaTest로, test만을 사용할 수 있다. 

2. allargs와 같은 형태를, test에서도 사용할 수 있다. 

3. sql파일을 활용해서 test할 수도 있다. 

 

 

 

이젠, Mock test를 보자 .

mockito 도구를 활용하여, mocktest를 진행한다. 

 

1. @INJECTIONMOCK -> MEMBERRSERVICE ( 행위를 TEST하고자 하는 MOCK을 주입받는다)

2. @MOCK -> MOCK으로, 그 내부에서 사용하는 REPOSITORY를 작성한다. 

 

 

given(memberrepository.findbyname("지혁")).willreturn(member)와 같이, 임의의 mock의 행위를 규정해준다.

*db와 연관되지 않아도 되는 장점이 있다. 

 

-허나, mock으로 테스트를 진행해도, 통합 테스트를 짜야하기 떄문에 매번 사용되는 것은 아니다 .

-API로써 제공받아서 사용하면, MOCK을 주로 사용한다 . 

 

 

이제. 통합 TEST를 보자. 

거의 모든 BEAN을 올리고, 실제 WEBMVC과정과 같은 경우도 TEST해본다. 

 

WEBMVC는 MOCKMVC로 TEST를 진행해야한다. 

*문제는, DATABASE에 입력될때 반드시 해당 TEST가 ROLLBACK이 진행되어야한다. 

간단하게, 테스트 CLASS에 @TRANSACTIONAL을 추가해주어야한다. 

 

 

readJson코드를 잘 기억해두자.

 

주로 난 이렇게 계층화 구조로 TEST를 작성할 것 같지는 않지만. 그래도 작성해 보았다.

 

메인 SERVICE에서는 GIVEN WHEN THEN으로 원하는 내용을 진행했고, 

그 부모에서는 BEFOREEACH를 활용하여 MOCKMVC를 통해 요청을 흉내냈다. 

 

회원가입의 예시로, 한 CLASS에서 말했던 것들의 동작을 진행한 코드 .

 

위 방식은 readjson이라는 method를 생성하여

원하는 곳에 json 형식의 request를 적어놓고, 이를 mockmvc에서 사용하게끔 하는 방식이다. 

이 방식 외에도, 만약 userdto에서 build가 가능하다면 user dto를 build해서 request에 맞게 형 변환하여

request로 쓸 수도 있다 

 

허나 , DTO에서 생성이 가능해야 한다는 문제를 기억하자 ! 

 

이런 식으로 말이다.

 

 

TRAVIS CI를 활용하여 

배포의 자동화와 자동화 테스트, 피드백등을 받을 수 있다. 

PULLREQUEST -> TRAVIS가 검사 -> 이후 PULL REQUEST가 잘 진행될지가 결정된다. 

 

JACOCO를 활용하면 코드의 커버리지를 측정할 수 있다.