[java] Mockito.verify ()를 언제 사용합니까?

이것은 좋은 질문입니다! 근본 원인은 다음과 같습니다. 단위 테스트뿐만 아니라 JUnit을 사용하고 있습니다. 따라서 질문은 분리되어야합니다.

• 통합 (또는 다른 단위 이상의 테스트) 테스트 에서 Mockito.verify ()를 사용해야 합니까?
• 블랙 박스 단위 테스트 에서 Mockito.verify ()를 사용해야 합니까?
• 화이트 박스 단위 테스트 에서 Mockito.verify ()를 사용해야 합니까?

만약 우리가 단위보다 높은 테스트를 무시한다면, ” Mockito.verify ()와 함께 화이트 박스 단위 테스트를 사용하면 단위 테스트와 가능한 구현 사이에 훌륭한 커플을 만들 수 있습니다. ” “ 단위 테스트와 이것에 어떤 규칙을 사용해야합니까 “.

이제이 모든 단계를 단계별로 살펴 보겠습니다.

*- 통합 (또는 다른 단위보다 높은 다른 테스트) 테스트 에서 Mockito.verify ()를 사용해야 합니까? * 대답은 분명히 아니오라고 생각합니다. 또한이를 위해 모의를 사용해서는 안됩니다. 테스트는 가능한 한 실제 응용 프로그램에 가깝습니다. 애플리케이션의 분리 된 부분이 아닌 완전한 유스 케이스를 테스트하고 있습니다.

* 블랙 박스 대 화이트 박스 단위 테스트 * 실제로 수행중인 블랙 박스 방식을 사용하는 경우 (모든 동등성 클래스) 입력, 상태 및 예상 출력을받을 테스트를 제공합니다. 이 접근법에서 모의 ​​사용은 일반적으로 정당화됩니다 (당신은 그들이 옳은 일을하고 있음을 모방하고 테스트하고 싶지는 않습니다). 그러나 Mockito.verify () 호출은 불필요한 것입니다.

실제 작업 을 화이트 박스 방식 으로 사용하는 경우 장치 의 동작 을 테스트하는 것 입니다. 이 접근 방식에서는 Mockito.verify ()를 호출하는 것이 필수적이므로 장치가 예상대로 작동하는지 확인해야합니다.

그레이 박스 테스트를위한 엄지 손가락 규칙
화이트 박스 테스트의 문제점은 높은 커플 링을 생성한다는 것입니다. 하나의 가능한 해결책은 화이트 박스 테스트가 아닌 그레이 박스 테스트를 수행하는 것입니다. 이것은 흑백 박스 테스트의 조합입니다. 화이트 박스 테스트와 같이 실제로 장치 의 동작 을 테스트하고 있지만 일반적으로 가능하면 구현에 무관 하게 만듭니다 . 가능하면 블랙 박스와 같이 검사를 수행하고 출력이 예상되는 것임을 주장합니다. 따라서 질문의 본질은 가능할 때입니다.

정말 어렵다. 좋은 예는 없지만 예를들 수 있습니다. 위에서 equals () vs equalsIgnoreCase ()로 언급 한 경우 Mockito.verify ()를 호출하지 말고 출력을 확인하십시오. 그렇게 할 수 없다면 코드를 더 작은 단위로 나누십시오. 반면에 @Service가 있고 @Service를 래퍼하는 @ Web-Service를 작성한다고 가정하면 모든 호출을 @Service에 위임하고 추가 오류 처리를 수행합니다. 이 경우 Mockito.verify ()를 호출하는 것이 필수적이므로 @Serive에 대해 수행 한 모든 검사를 복제하지 않아야합니다. 올바른 매개 변수 목록으로 @Service를 호출하는 것이 충분한 지 확인하십시오.

답변