@ParameterizedTest
테스트코드내에 if문이라던가 for문은 읽는 사람의 생각을 요하는 로직들이 들어가는 경우는 지향해야한다.
단순하게 하나의 케이스인데 값을 여러 개로 바꿔보면서 테스트하고싶은경우 이럴때 사용하는게 @ParameterizedTest이다
값이나 환경을 바꿔가면서 여러번 테스트하고싶을때 사용하는것이다이렇게 짯다고 가정
이경우는 너무 케이스가 많아보이고 어떤 결과인지 보기가 힘들다.
모든타입에 대해서 테스트하고싶다고 가정하면 이런거를 다 테스트하고싶은데 이런경우는 한가지 케이스는 맞지만 모든 경우를 테스트하고싶을때 사용하는게 파라미터라이즈테스트다.
개선하면 아래와 같다
소스를 줄수있는데 CsVSource를 사용한다 CsVSource란 콤마로 구분하는것이다.
이값들은 파라미터로 나눠서 들어온다
별도의 메소드로 빼서도 가능하다 Source는 다양하다 찾아보면 좋겠다
팁은 어찌보면 메소드도 given절이라서 테스트바로 위쪽에 작성하는게 좋다
찾아보면서 인상깊은것은 NullSource넣으면은 이것도 자동으로 테스트해주고 그외의 값은 ValueSource로 가능하다. 공식문서를 참고하자
이경우는 보면 값넣고 테스트 수행결과 displayname에 표시되도록하는것이다
@DynamicTest
공유변수를 사용하는것을 지양하자고했다. 이런 케이스말고 어떤 하나의 환경을 설정해놓고 사용자의 시나리오를 테스트하고싶을때가있다. 이럴때 사용하기 좋은게 DynamicTest이다.
ex) 재고1차감하고 다시 차감하는경우
테스트환경 통합하기
테스트 수행도 비용이다
전체테스트는 기능을 다 개발하고 푸시하기전에 전체테스트를 한번 돌려보아라
숏컷으로 단축키 등록하는것도 팁임
스프링부트가 통합테스트일때 띄워지는데 너무 많이 나온다
Controller테스트일때 자주뜬다 이러한 시간이 어느정도 걸리게된다
테스트가 많아질수록 전체테스트 수행시간이 길어진다.
따로뜨는이유는 환경이 달라서이기때문이다. 그래서 공통적인 환경을 만들면은
서버뜨는 시간을 줄일 수 있게된다. 통합하는 방법은 상위클래스를 만들어서 추출한다.
MockBean도 차이나면 환경이다른건데 이것을 통합쪽으로 올리는것도 방법임. 그런데 다른서비스에서도 들어가서 조금의 문제 이럴때는 순수목처리와 목빈처리없는 환경2개로 나눠서 하는것도 방법이다
Private메소드 테스트
Private메소드는 할필요도없고 해서도 안된다.
이때는 객체를 분리할 시점인가라는 생각을 가져야한다 클라이언트 입장에서는 공개API만 알면되기때문이다. 클라이언트(컨트롤러)등등 공개되지않은것도 굳이 알아야할 필요가없기때문이다.
퍼블릭 메소드A가있고 private메소드 B가있는데
A에서는 B를 호출하는데 A를검증하면 B가 자동으로 검증할 수 있기때문에 해야할 필요가없다고 말하는것이다.
만약하려면 꼭 테스트를 하고싶다면 객체분리를 분리해라.
테스트에서만 필요한 메서드가 생겼는데 프로덕션 코드에서는 필요 없다면?
빌더나 생성자는 테스트에서만 사용한다 그런데 순수하게 빌더랑 생성자로 텍스트픽쳐를 만드는게 제일 베스트 테스트 환경의 독립성을 보장하자라는 것이다(목적이 들어간 생성이기때문에).
정리하면 프론트에서 값 주면은 생성자나 빌더 잘 사용안하고 requeset를 바로 팩토리 메서드로 변환하는데 이런것보단 사용자가 직접값주는것처럼 하기위해서는 만들어서 넣는 환경을 하는것이다.
그래서 request를 변환한값이나 이런것보다 생성자나 빌더를 사용하자.
학습테스트
테스트를 도구로 사용하는것
- 잘 모르는 기능, 라이브러리, 프레임워크를 학습하기 위해 작성하는 테스트
- 여러 테스트 케이스를 스스로 정의하고 검증하는 과정을 통해 보다 구체적인 동작과 기능을 학습할 수 있다.
- 관련 문서만 읽는 것보다 훨씬 재미있게 학습할 수 있다.
https://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests
