問(wèn)題描述

我正在研究為我的項(xiàng)目使用哪個(gè)模擬框架，并將其范圍縮小到 JMockit 和 Mockito.

I'm investigating which mocking framework to use for my project and have narrowed it down to JMockit and Mockito.

我注意到 Mockito 被選為the最好的 Java 模擬框架"在 Stackoverflow 上.
在比較 JMockit 的模擬工具的功能時(shí)比較矩陣"，JMockit 似乎有多種不同的特征.

I notice that Mockito was voted "the best mock framework for Java" on Stackoverflow.
In comparing features on JMockit's "Mocking Tool Comparision Matrix" it appears that JMockit has multiple different features.

對(duì)于 Mockito 可以做什么而 JMockit 無(wú)法實(shí)現(xiàn)的事情，是否有人有任何具體信息(不是意見(jiàn))，反之亦然?

Does anyone have any specific information (not opinions) on what Mockito can do which can't be achieved with JMockit and vice versa?

推薦答案

2019年9月更新:唯一的Spring Boot 支持的模擬框架(默認(rèn)) 是 Mockito.如果你使用 Spring，答案就很明顯了.

Update Sep 2019: The only mocking framework supported (by default) by Spring Boot is Mockito. If you use Spring, the answer is quite obvious.

我想說(shuō)的是JMockit和PowerMock之間的競(jìng)爭(zhēng)，然后是Mockito.

I'd say the competition is between JMockit and PowerMock, then Mockito.

我會(huì)留下普通"的 jMock 和 EasyMock，因?yàn)樗鼈冎皇褂么砗虲GLIB，并且不要像新框架那樣使用 Java 5 工具.

I'd leave "plain" jMock and EasyMock because they use only proxy & CGLIB and do not use Java 5 instrumentation like the newer frameworks.

jMock 也有超過(guò) 4 年沒(méi)有穩(wěn)定的版本.jMock 2.6.0 從 RC1 升級(jí)到 RC2 需要 2 年，然后再需要 2 年才能真正發(fā)布.

jMock also didn't have a stable release for over 4 years. jMock 2.6.0 required 2 years to go from RC1 to RC2, and then another 2 years before it actually got released.

關(guān)于代理和CGLIB 與儀表:

Regarding Proxy & CGLIB vs instrumentation:

(EasyMock 和 jMock)基于 java.lang.reflect.Proxy，這需要一個(gè)接口實(shí)施的.此外，他們支持創(chuàng)建模擬對(duì)象對(duì)于通過(guò) CGLIB 子類的類一代.正因?yàn)槿绱耍f(shuō)類不能是最終的，只有可覆蓋的實(shí)例方法可以是嘲笑.然而，最重要的是，使用這些工具時(shí)被測(cè)代碼的依賴項(xiàng)(即是，其他類的對(duì)象哪個(gè)給定的類正在測(cè)試取決于)必須由控制測(cè)試，以便模擬實(shí)例可以傳遞給那些客戶依賴關(guān)系.因此，依賴不能簡(jiǎn)單地用客戶端類中的新運(yùn)算符我們要編寫單元測(cè)試.

(EasyMock and jMock) are based on java.lang.reflect.Proxy, which requires an interface to be implemented. Additionally, they support the creation of mock objects for classes through CGLIB subclass generation. Because of that, said classes cannot be final and only overridable instance methods can be mocked. Most importantly, however, when using these tools the dependencies of code under test (that is, the objects of other classes on which a given class under test depends) must be controlled by the tests, so that mock instances can be passed to the clients of those dependencies. Therefore, dependencies can't simply be instantiated with the new operator in a client class for which we want to write unit tests.

最終，技術(shù)限制傳統(tǒng)的模擬工具強(qiáng)加以下設(shè)計(jì)限制生產(chǎn)代碼:

Ultimately, the technical limitations of conventional mocking tools impose the following design restrictions on production code:

1. 在測(cè)試中可能需要模擬的每個(gè)類都必須實(shí)現(xiàn)一個(gè)單獨(dú)的接口或不是最終的.
2. 每個(gè)要測(cè)試的類的依賴必須要么獲取通過(guò)可配置的實(shí)例創(chuàng)建方法(工廠或服務(wù)定位器)，或暴露于依賴注射.否則，單元測(cè)試不會(huì)能夠通過(guò)模擬實(shí)現(xiàn)對(duì)下屬單位的依賴測(cè)試.
3. 由于只能模擬實(shí)例方法，因此要對(duì)類進(jìn)行單元測(cè)試不能調(diào)用任何靜態(tài)方法它們的依賴關(guān)系，也不實(shí)例化他們使用任何構(gòu)造函數(shù).

以上內(nèi)容復(fù)制自 http://jmockit.org/about.html .此外，它還通過(guò)多種方式在自身 (JMockit)、PowerMock 和 Mockito 之間進(jìn)行比較:

The above is copied from http://jmockit.org/about.html . Further, it compares between itself (JMockit), PowerMock, and Mockito in several ways:

現(xiàn)在有其他模擬工具Java里面也克服了傳統(tǒng)方法的局限，它們之間有 PowerMock、jEasyTest 和模擬注入.最接近的那個(gè)JMockit 的功能集是PowerMock，所以我將簡(jiǎn)要評(píng)估一下它在這里(此外，其他兩個(gè)是更有限，似乎不是不再積極開(kāi)發(fā)).

There are now other mocking tools for Java which also overcome the limitations of the conventional ones, between them PowerMock, jEasyTest, and MockInject. The one that comes closest to the feature set of JMockit is PowerMock, so I will briefly evaluate it here (besides, the other two are more limited and don't seem to be actively developed anymore).

• 首先，PowerMock沒(méi)有提供完整的模擬API，而是作為擴(kuò)展另一種工具，目前可以EasyMock 或 Mockito.這顯然是現(xiàn)有用戶的優(yōu)勢(shì)那些工具.
• 另一方面，JMockit 提供了全新的 API，盡管它的主要API(期望)是相似的EasyMock 和 jMock.雖然這創(chuàng)造了更長(zhǎng)的學(xué)習(xí)曲線，它還允許 JMockit 提供一個(gè)更簡(jiǎn)單、更一致、更容易使用 API.
• 與 JMockit Expectations API 相比，PowerMock API 是更低級(jí)"，迫使用戶找出并指定哪些類需要為測(cè)試做好準(zhǔn)備(與@PrepareForTest({ClassA.class,...}) 注釋)并要求特定的 API 調(diào)用來(lái)處理各種語(yǔ)言結(jié)構(gòu)生產(chǎn)中可能存在的代碼:靜態(tài)方法(mockStatic(ClassA.class)),構(gòu)造函數(shù)(抑制(構(gòu)造函數(shù)(ClassXyz.class)))，構(gòu)造函數(shù)調(diào)用(expectNew(AClass.class)), 部分模擬(createPartialMock(ClassX.class，"methodToMock")) 等.
• 有了JMockit Expectations，各種方法和構(gòu)造函數(shù)以純粹的聲明方式嘲笑，通過(guò)指定的部分模擬@Mocked 中的正則表達(dá)式注釋或簡(jiǎn)單地取消模擬"沒(méi)有記錄的成員期望;也就是開(kāi)發(fā)商簡(jiǎn)單地聲明一些共享的模擬字段"用于測(cè)試類，或一些本地模擬字段"和/或模擬參數(shù)"用于個(gè)別測(cè)試方法(在最后一種情況下@Mocked 注釋通常不會(huì)需要).
• JMockit 中的一些可用功能，例如對(duì)模擬的支持等于和 hashCode，被覆蓋方法和其他方法目前還沒(méi)有PowerMock 支持.此外，還有不等同于 JMockit 的能力捕獲實(shí)例并模擬指定基礎(chǔ)的實(shí)現(xiàn)類型作為測(cè)試執(zhí)行，沒(méi)有測(cè)試代碼本身有任何實(shí)際執(zhí)行的知識(shí)類.
• PowerMock 使用自定義類加載器(通常每個(gè)測(cè)試類一個(gè))為了生成修改版本的嘲笑類.如此大量的使用的自定義類加載器可能導(dǎo)致與第三方庫(kù)沖突，因此有時(shí)需要使用@PowerMockIgnore("package.to.be.ignored")測(cè)試類的注釋.
• JMockit 使用的機(jī)制(通過(guò)Java 代理")更簡(jiǎn)單、更安全，雖然它確實(shí)需要通過(guò)-javaagent"參數(shù)到 JVM 時(shí)在 JDK 1.5 上開(kāi)發(fā)；在 JDK 1.6+(它總是可以用于開(kāi)發(fā)，即使部署在舊版本)沒(méi)有這樣的要求，因?yàn)?JMockit 可以透明地加載 Java 代理使用 Attach API 來(lái)滿足需求.

另一個(gè)最近的模擬工具是莫基托.雖然沒(méi)有嘗試克服老年人的局限工具(jMock，EasyMock)，它確實(shí)引入一種新的行為方式用模擬測(cè)試.JMockit 也支持這種另類風(fēng)格，通過(guò) Verifications API.

Another recent mocking tool is Mockito. Although it does not attempt to overcome the limitations of older tools (jMock, EasyMock), it does introduce a new style of behavior testing with mocks. JMockit also supports this alternative style, through the Verifications API.

• Mockito 依賴對(duì)其 API 的顯式調(diào)用來(lái)分離代碼記錄之間 (when(...)) 和驗(yàn)證(驗(yàn)證(...))階段.這意味著對(duì)模擬的任何調(diào)用測(cè)試代碼中的對(duì)象也需要對(duì)模擬 API 的調(diào)用.此外，這通常會(huì)導(dǎo)致重復(fù) when(...) 和驗(yàn)證(模擬)...調(diào)用.
• 使用 JMockit，不存在類似的調(diào)用.當(dāng)然，我們有新的NonStrictExpectations() 和新的Verifications() 構(gòu)造函數(shù)調(diào)用，但是它們每次測(cè)試只發(fā)生一次(通常)，并且完全與調(diào)用分開(kāi)模擬方法和構(gòu)造函數(shù).
• Mockito API 在用于對(duì)模擬方法的調(diào)用.在里面記錄階段，我們有這樣的電話何時(shí)(mock.mockedMethod(args))...而在驗(yàn)證階段這個(gè)相同的調(diào)用將被寫為驗(yàn)證(模擬).mockedMethod(參數(shù)).請(qǐng)注意，在第一種情況下調(diào)用 mockedMethod直接在模擬對(duì)象上，而在第二種情況是在verify(mock) 返回的對(duì)象.
• JMockit 沒(méi)有這樣的不一致，因?yàn)檎{(diào)用總是制作模擬方法直接在模擬實(shí)例上他們自己.(只有一個(gè)例外:匹配相同的調(diào)用模擬實(shí)例，一個(gè) onInstance(mock)調(diào)用被使用，導(dǎo)致代碼像onInstance(mock).mockedMethod(args);大多數(shù)測(cè)試不需要使用它，不過(guò).)
• 就像其他依賴方法的模擬工具一樣鏈接/包裝，Mockito 也運(yùn)行存根時(shí)語(yǔ)法不一致無(wú)效的方法.例如，你寫when(mockedList.get(1)).thenThrow(new運(yùn)行時(shí)異常())；對(duì)于非空方法和 doThrow(newRuntimeException()).when(mockedList).clear();對(duì)于一個(gè)無(wú)效的.使用 JMockit，它是總是相同的語(yǔ)法:mockedList.clear();結(jié)果=新運(yùn)行時(shí)異常()；.
• 在使用 Mockito 間諜時(shí)還存在另一個(gè)不一致之處:模擬"允許真正的方法是在間諜實(shí)例上執(zhí)行.為了例如，如果 spy 指的是一個(gè)空的列出，然后而不是寫when(spy.get(0)).thenReturn("foo") 你需要寫doReturn("foo").when(spy).get(0).和JMockit，動(dòng)態(tài)模擬功能提供類似的功能間諜，但沒(méi)有這個(gè)問(wèn)題，因?yàn)檎嬲姆椒ㄖ辉谥夭ルA段.
• 在 EasyMock 和 jMock(Java 的第一個(gè)模擬 API)中，重點(diǎn)是完全基于預(yù)期的記錄模擬方法的調(diào)用，對(duì)于(默認(rèn)情況下)不模擬的對(duì)象允許意外調(diào)用.那些API 還提供記錄允許對(duì)模擬對(duì)象的調(diào)用確實(shí)允許意外調(diào)用，但這被視為二等特征.此外，有了這些工具沒(méi)有辦法明確在被測(cè)代碼被執(zhí)行.所有這樣的隱式執(zhí)行驗(yàn)證并自動(dòng)進(jìn)行.
• 在 Mockito(以及 Unitils Mock)中，相反的觀點(diǎn)是采取.對(duì)模擬對(duì)象的所有調(diào)用在測(cè)試期間可能發(fā)生的情況，無(wú)論是否記錄，都允許，沒(méi)想到.驗(yàn)證是在代碼之后顯式執(zhí)行在測(cè)試中被行使，從不自動(dòng).
• 這兩種方法都過(guò)于極端，因此都不是最優(yōu)的.JMockit 期望與驗(yàn)證是唯一允許開(kāi)發(fā)人員可以無(wú)縫選擇嚴(yán)格的最佳組合(預(yù)期默認(rèn)情況下)和非嚴(yán)格(允許默認(rèn))為每個(gè)模擬調(diào)用測(cè)試.
• 更清楚地說(shuō)，Mockito API 有以下缺點(diǎn).如果你需要驗(yàn)證對(duì) a 的調(diào)用非空模擬方法發(fā)生在測(cè)試，但測(cè)試需要一個(gè)從該方法返回值是不同于默認(rèn)的返回類型，然后是 Mockito 測(cè)試將有重復(fù)的代碼:awhen(mock.someMethod()).thenReturn(xyz)在記錄階段調(diào)用，以及verify(mock).someMethod() 在驗(yàn)證階段.使用 JMockit，一個(gè)嚴(yán)格的期待總能被記錄，不必明確已驗(yàn)證.或者，調(diào)用計(jì)數(shù)約束(次 = 1)可以是指定用于任何記錄的非嚴(yán)格期望(與 Mockito 這樣的約束只能在一個(gè)驗(yàn)證(模擬，約束)調(diào)用).
• Mockito 的語(yǔ)法很差，無(wú)法按順序進(jìn)行驗(yàn)證驗(yàn)證(即，檢查所有對(duì)模擬對(duì)象的調(diào)用都是明確驗(yàn)證).在第一情況下，需要一個(gè)額外的對(duì)象創(chuàng)建，并調(diào)用驗(yàn)證它: InOrder inOrder = inOrder(mock1,模擬2，...).在第二種情況下，調(diào)用像 verifyNoMoreInteractions(mock) 或verifyZeroInteractions(mock1, mock2)需要制作.
• 使用 JMockit，您只需編寫 new VerificationsInOrder() 或 newFullVerifications() 而不是 new驗(yàn)證()(或新FullVerificationsInOrder() 結(jié)合兩個(gè)要求).無(wú)需指定涉及哪些模擬對(duì)象.不額外的模擬 API 調(diào)用.而作為一個(gè)獎(jiǎng)金，通過(guò)調(diào)用unverifiedInvocations() 內(nèi)有序的驗(yàn)證塊，你可以執(zhí)行與訂單相關(guān)的驗(yàn)證這在 Mockito 中根本不可能.

最后，JMockit 測(cè)試工具包范圍更廣并且更有野心目標(biāo) 比其他模擬工具包，在為了提供一個(gè)完整的和復(fù)雜的開(kāi)發(fā)人員測(cè)試解決方案.一個(gè)很好的模擬 API，甚至沒(méi)有人為的限制，不是足以生產(chǎn)性地創(chuàng)造測(cè)試.與 IDE 無(wú)關(guān)，易于使用，和集成良好的代碼覆蓋率工具也是必不可少的，這就是JMockit Coverage 旨在提供.開(kāi)發(fā)人員測(cè)試的另一部分將變得更有用的工具集隨著測(cè)試套件規(guī)模的擴(kuò)大，增量重新運(yùn)行測(cè)試的能力在對(duì)生產(chǎn)進(jìn)行局部更改后代碼;這也包含在覆蓋工具.

Finally, the JMockit Testing Toolkit has a wider scope and more ambitious goals than other mocking toolkits, in order to provide a complete and sophisticated developer testing solution. A good API for mocking, even without artificial limitations, is not enough for productive creation of tests. An IDE-agnostic, easy to use, and well integrated Code Coverage tool is also essential, and that's what JMockit Coverage aims to provide. Another piece of the developer testing toolset which will become more useful as the test suite grows in size is the ability to incrementally rerun tests after a localized change to production code; this is also included in the Coverage tool.

(當(dāng)然，來(lái)源可能有偏見(jiàn)，但好吧......)

(granted, the source may be biased, but well...)

我會(huì)說(shuō)使用 JMockit.當(dāng)您無(wú)法控制要測(cè)試的類(或由于兼容性等原因而無(wú)法破壞它)時(shí)，它最容易使用、靈活，并且適用于幾乎所有情況，甚至是困難的情況和場(chǎng)景.

I'd say go with JMockit. It's the easiest to use, flexible, and works for pretty much all cases even difficult ones and scenarios when you can't control the class to be tested (or you can't break it due to compatibility reasons etc.).

我對(duì) JMockit 的體驗(yàn)非常積極.

My experiences with JMockit have been very positive.

這篇關(guān)于Mockito 與 JMockit 之間的比較 - 為什么 Mockito 的投票比 JMockit 好?的文章就介紹到這了，希望我們推薦的答案對(duì)大家有所幫助，也希望大家多多支持html5模板網(wǎng)！