問題描述
我為 3 個目的編寫 jUnit 測試用例:
I write jUnit test cases for 3 purposes:
- 為了確保我的代碼在所有(或大部分)輸入組合/值下滿足所有必需的功能.
- 為了確保我可以更改實現，并依靠 JUnit 測試用例告訴我我的所有功能仍然得到滿足.
- 作為我的代碼處理的所有用例的文檔，并充當重構規范 - 如果代碼需要重寫.(重構代碼，如果我的 jUnit 測試失敗 - 你可能錯過了一些用例).
我不明白為什么或何時應該使用 Mockito.verify().當我看到 verify() 被調用時，它告訴我我的 jUnit 正在意識到該實現.(因此更改我的實現會破壞我的 jUnit，即使我的功能不受影響).
I do not understand why or when Mockito.verify() should be used. When I see verify() being called, it is telling me that my jUnit is becoming aware of the implementation. (Thus changing my implementation would break my jUnits, even though my functionality was unaffected).
我正在尋找:
正確使用
Mockito.verify()的指南應該是什么?
jUnits 了解或緊密耦合到被測類的實現是否從根本上正確?
Is it fundamentally correct for jUnits to be aware of, or tightly coupled to, the implementation of the class under test?
推薦答案
如果類 A 的契約包括它調用 C 類型對象的方法 B 的事實，那么您應該通過制作 C 類型的模擬來測試這一點，并驗證方法 B 是否已被調用.
If the contract of class A includes the fact that it calls method B of an object of type C, then you should test this by making a mock of type C, and verifying that method B has been called.
這意味著類 A 的契約有足夠的細節來討論類型 C(可能是接口或類).所以是的，我們談論的規范級別不僅僅是系統要求"，而是在某種程度上描述了實現.
This implies that the contract of class A has sufficient detail that it talks about type C (which might be an interface or a class). So yes, we're talking about a level of specification that goes beyond just "system requirements", and goes some way to describing implementation.
這對于單元測試是正常的.當您進行單元測試時，您希望確保每個單元都在做正確的事情"，這通常包括它與其他單元的交互.這里的單元"可能是指類或應用程序的更大子集.
This is normal for unit tests. When you are unit testing, you want to ensure that each unit is doing the "right thing", and that will usually include its interactions with other units. "Units" here might mean classes, or larger subsets of your application.
更新:
我覺得這不僅適用于驗證，也適用于存根.一旦您存根協作者類的方法，您的單元測試就在某種意義上變得依賴于實現.這有點像單元測試的性質.由于 Mockito 與驗證一樣重要，因此您使用 Mockito 的事實意味著您將遇到這種依賴關系.
I feel that this doesn't apply just to verification, but to stubbing as well. As soon as you stub a method of a collaborator class, your unit test has become, in some sense, dependent on implementation. It's kind of in the nature of unit tests to be so. Since Mockito is as much about stubbing as it is about verification, the fact that you're using Mockito at all implies that you're going to run across this kind of dependency.
根據我的經驗，如果我改變一個類的實現，我經常不得不改變它的單元測試的實現來匹配.不過，通常情況下，我不必更改類是的單元測試清單；當然，除非更改的原因是存在我之前未能測試的條件.
In my experience, if I change the implementation of a class, I often have to change the implementation of its unit tests to match. Typically, though, I won't have to change the inventory of what unit tests there are for the class; unless of course, the reason for the change was the existence of a condition that I failed to test earlier.
這就是單元測試的意義所在.不受這種對協作者類使用方式的依賴影響的測試實際上是子系統測試或集成測試.當然，這些也經常使用 JUnit 編寫，并且經常涉及到 mocking 的使用.在我看來，JUnit"是一個糟糕的名字，因為它可以讓我們進行所有不同類型的測試.
So this is what unit tests are about. A test that doesn't suffer from this kind of dependency on the way collaborator classes are used is really a sub-system test or an integration test. Of course, these are frequently written with JUnit too, and frequently involve the use of mocking. In my opinion, "JUnit" is a terrible name, for a product that lets us produce all different types of test.
這篇關于何時使用 Mockito.verify()?的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網！