MockMvc

• Mock(가짜) 객체를 사용해 스프링 MVC 동작을 재현할 수 있는 테스트 프레임워크

   

   

Test Double

• Dummy

  • 아무 것도 하지 않는 깡통 객체

• Fake

  • 단순한 형태로 동일한 기능은 수행하나, 프로덕션에서 쓰기에는 부족한 객체

• Stub (상태검증)

  • 테스트에서 요청한 것에 대해 미리 준비한 결과를 제공하는 객체 그 외에는 응답하지 않는다.

• Spy

  • Stub이면서 호출된 내용을 기록하여 보여줄 수 있는 객체 일부는 실제 객체처럼 동작 시키고 일부만 Stubbing 할 수 있다.

• Mock (행위검증)

  • 행위에 대한 기대를 명세하고, 그에 따라 동작하도록 만들어진 객체

BDDMockito

BDD : 행동 주도 개발

Mockito 를 한번 감싸서 호출하는 것 뿐

한 문단에 한 주제!

완벽하게 제어하기

• DateTime.Now 처럼 제어하지 못하는 것 보다는 제어 할 수 있는 부분으로 변경

• 외부 시스템을 이용해야하는 경우는 Mock 을 활용하여 처리

테스트 환경의 독립성을 보장하자

• 테스트는 given 에서 문제가 발생하지 않도록, 문제는 when, then 에서 나게 유도 생성자를 활용하여 처리하는 걸 추천

테스트 간 독립성을 보장하자

• 공유자원을 활용하여 처리를 하는 경우 서로에게 영향이 갈 수가 있음

한 눈에 들어오는 Test Fixture 구성하기

• Fixture : 고정물, 고정되어 있는 물체

• 테스트를 위해 원하는 상태로 고정시킨 일련의 객체

• @BeforeAll, @BeforeEach 는 아래 질문에 부합할 때 사용!! 테스트 내용을 히애하는데 문제가 없는가? 수정해도 모든 테스트에 영향을 주지 않는가??

• 테스트에 필요한 것만 생성을 할 수 있도록 간편하게 적용

• 테스트에서 중복으로 사용하게 되는 함수나 클래스등을 모아서 처리 하는 방식은 모아둔 곳이 거대해져서 더 안 좋아 질 수도 있음

deleteAllInBatch

• 연관관계와 다르게 순서를 안 지키면 삭제 안됨

• DELETE 만 발생

deleteAll

• 전체 조회 후 외래키와 관계된 데이터를 건마다 삭제

• ALL select → EACH delete

• 다수의 쿼리로 인해 많은 비용이 발생

@Parameterized Test

• 단 하나의 테스트 인데 값을 바꿔가면서 테스트 하고 싶을 떄

@DynamicTest

• 시나리오 작성하듯이 순차적으로 테스트 발생 시킬 수 있음

테스트 수행도 비용이다!

• 통합테스트를 하게 되면 스프링부트가 중복으로 많이 호출 되게 됨

• 같은 @SpringBootTest 라도 조금이라도 다르면 다시 호출 됨

• 새롭게 스캔해야하는 경우에도 다시 호출 ex) MockBean

• MockBean 을 사용하는 것과 안하는 것 두개를 나눠서 처리 해도 됨

• 서버를 뜨는 시간을 줄이는 것이 테스트 양이 많아 질수록 이득

Private 메서드의 테스트는 어떻게 하나요??

• 테스트를 할 필요가 없다(?)

  • 객체를 분리할 시점인가?? 확인

• Public Method 를 테스트 하다보면 Private Method 는 자연스럽게 검증이 됨

테스트에서만 필요한 메서드가 생겼는데 프로덕션 코드에서는 필요 없다면??

• 만들어도 된다. 하지만 보수적으로 접근하기