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

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

---

3 가지 목적으로 jUnit 테스트 사례를 작성합니다.

1. 내 코드가 모든 (또는 대부분의) 입력 조합 / 값 하에서 필요한 기능을 모두 충족 시키려면.
2. 구현을 변경하고 JUnit 테스트 사례를 사용하여 모든 기능이 여전히 만족 스럽다는 것을 알려줍니다.
3. 코드를 다시 작성해야하는 경우 내 코드가 처리하고 리팩토링 사양으로 작동하는 모든 사용 사례에 대한 문서입니다. (코드를 리팩터링하고 jUnit 테스트가 실패하면 유스 케이스를 놓친 것 같습니다).

왜 또는 언제 Mockito.verify()사용해야하는지 이해하지 못합니다 . verify()호출 된 것을 볼 때 jUnit이 구현을 인식하고 있음을 알려줍니다. (따라서 내 기능이 영향을받지 않더라도 구현을 변경하면 jUnit이 손상됩니다).

내가 찾고 있어요:

1. 적절한 사용법에 대한 지침은 무엇입니까 Mockito.verify()?

2. jUnit이 테스트중인 클래스의 구현을 인식하거나 밀접하게 결합하는 것이 근본적으로 정확합니까?

---

클래스 A의 계약에 유형 C의 오브젝트의 메소드 B를 호출한다는 사실이 포함 된 경우, 유형 C의 모형을 작성하고 메소드 B가 호출되었는지 확인하여이를 테스트해야합니다.

이는 클래스 A의 계약에 유형 C (인터페이스 또는 클래스 일 수 있음)에 대해 충분한 세부 사항이 있음을 의미합니다. 그렇습니다. 우리는 단지 "시스템 요구 사항"을 넘어서서 구현을 설명하는 어떤 수준의 사양에 대해 이야기하고 있습니다.

이것은 단위 테스트에서 정상입니다. 단위 테스트를 수행 할 때 각 단위가 "올바른 일"을하고 있는지 확인하고 다른 단위와의 상호 작용을 포함해야합니다. 여기서 "단위"는 클래스 또는 응용 프로그램의 더 큰 하위 집합을 의미 할 수 있습니다.

최신 정보:

나는 이것이 검증에만 적용되는 것이 아니라 스터 빙에도 적용된다고 생각합니다. 공동 작업자 클래스의 메소드를 스텁하자마자 단위 테스트는 구현에 따라 일부 의미가 있습니다. 그것은 단위 테스트의 성격 상 그러합니다. Mockito는 검증만큼이나 스터 빙에 관한 것이기 때문에 Mockito를 전혀 사용한다는 사실은 이러한 종류의 의존성을 극복해야한다는 것을 의미합니다.

경험상 클래스 구현을 변경하면 단위 테스트 구현을 일치하도록 변경해야하는 경우가 종종 있습니다. 일반적으로,하지만, 나는 거기에 어떤 단위 테스트의 재고 변경할 필요가 없습니다 것 입니다 클래스에 대해를; 물론이 아닌 한, 변경 이유는 내가 이전에 테스트하지 못한 상태가 존재했기 때문입니다.

이것이 단위 테스트에 관한 것입니다. 협력자 클래스가 사용되는 방식에 대한 이러한 종류의 종속성을 겪지 않는 테스트는 실제로 서브 시스템 테스트 또는 통합 테스트입니다. 물론 이것들은 종종 JUnit으로 작성되며 종종 모의 사용을 포함합니다. 제 생각에 "JUnit"은 모든 다른 유형의 테스트를 생성 할 수있는 제품의 끔찍한 이름입니다.

---

David의 대답은 물론 정확하지만 왜 이것을 원할지는 잘 설명하지 못합니다.

기본적으로 단위 테스트시 기능 단위를 개별적으로 테스트합니다. 입력이 예상 출력을 생성하는지 테스트합니다. 때로는 부작용도 테스트해야 할 때가 있습니다. 간단히 말해 확인하면 그렇게 할 수 있습니다.

예를 들어 DAO를 사용하여 물건을 저장 해야하는 약간의 비즈니스 논리가 있습니다. 통합 테스트를 사용하여 DAO를 인스턴스화하고이를 비즈니스 로직에 연결 한 다음 데이터베이스에서 펑크하여 예상되는 항목이 저장되었는지 확인할 수 있습니다. 그것은 더 이상 단위 테스트가 아닙니다.

또는 DAO를 조롱하여 예상대로 호출되는지 확인할 수 있습니다. mockito를 사용하면 무언가가 호출되는지, 얼마나 자주 호출되는지 확인하고, 매개 변수에 대해 매처를 사용하여 특정 방식으로 호출되도록 할 수 있습니다.

이와 같은 단위 테스트의 반대 측면은 실제로 리팩토링을 조금 더 어렵게 만드는 구현에 테스트를 묶는 것입니다. 다른 한편으로, 좋은 디자인 냄새는 제대로 운동하는 데 필요한 코드의 양입니다. 테스트가 매우 길어야하는 경우 설계에 문제가있을 수 있습니다. 따라서 테스트해야 할 부작용 / 복잡한 상호 작용이 많은 코드는 바람직하지 않습니다.

---

이것은 좋은 질문입니다! 근본 원인은 다음과 같습니다. 단위 테스트뿐만 아니라 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를 호출하는 것이 충분한 지 확인하십시오.

---

나는 당신이 고전적인 접근법의 관점에서 절대적으로 옳다고 말해야합니다.

• If you first create (or change) business logic of your application and then cover it with (adopt) tests (Test-Last approach), then it will be very painful and dangerous to let tests know anything about how your software works, other than checking inputs and outputs.
• If you are practicing a Test-Driven approach, then your tests are the first to be written, to be changed and to reflect the use cases of your software's functionality. The implementation depends on tests. That sometimes mean, that you want your software to be implemented in some particular way, e.g. rely on some other component's method or even call it a particular amount of times. That is where Mockito.verify() comes in handy!

It is important to remember, that there are no universal tools. The type of software, it's size, company goals and market situation, team skills and many other things influence the decision on which approach to use at your particular case.

---

As some people said

1. Sometimes you don't have a direct output on which you can assert
2. Sometimes you just need to confirm that your tested method is sending the correct indirect outputs to its collaborators (which you are mocking).

Regarding your concern about breaking your tests when refactoring, that is somewhat expected when using mocks/stubs/spies. I mean that by definition and not regarding a specific implementation such as Mockito. But you could think in this way - if you need to do a refactoring that would create major changes on the way your method works, it is a good idea to do it on a TDD approach, meaning you can change your test first to define the new behavior (that will fail the test), and then do the changes and get the test passed again.

참고URL : https://stackoverflow.com/questions/12539365/when-to-use-mockito-verify