프로젝트/리팩토링

testing의 전략을 수립하자.

임지혁코딩 2024. 1. 21. 16:00

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를 활용하면 코드의 커버리지를 측정할 수 있다.