如果要編寫輕量級的JUnit測試， Mockito是我最喜歡的小幫手。 如有必要，可以通過模擬輕松地替換被測單元的“實際”依賴關系，這非常有用。 尤其是在處理框架API的邊界線時，此類依賴項的設置否則可能非常昂貴。

但是有時候情況要復雜一些。 例如，如果測試出于某種原因需要與至少一個屬于這種框架的真實實例進行交互。 如果此交互包括將模擬作為參數(shù)傳遞給此實例，那么很幸運，實現(xiàn)會將參數(shù)強制轉(zhuǎn)換為從交互器的角度來看未知的類型。

這是一個簡單的例子來澄清這一點：

public interface Foo {[...] }public class Bar {public Bar( Foo foo ) {Runnable runnable = ( Runnable )foo;runnable.run();}[...] }public class SomeTest {@Testpublic void testConstructor() {Foo fooMock = mock( Foo.class );// fails with ClassCastExceptionBar bar = new Bar( fooMock );[...]} }

可以將Bar類視為需要某種實現(xiàn)的框架代碼。 由于參數(shù)類型Foo不能反映這種期望，因此將Foo模擬傳遞給Bar的構造函數(shù)將導致測試失敗，并帶有ClassCastException 。

也許您在想到上述情況時首先想到的是，框架通過強制轉(zhuǎn)換為未聲明的類型而變得很糟，并且最好將所有內(nèi)容扔掉并重新開始，從而更好！

不幸的是，在現(xiàn)實世界中，這種行為可以說是有效的。 例如， Eclipse平臺具有許多被聲明為“不打算由客戶端實現(xiàn)”的接口。 一個很好的例子就是團隊API的IHistoryView接口。 可以肯定地使用3.x平臺，盡管IHistoryView實現(xiàn)擴展了IViewPart ，但是歷史視圖界面并未公開這一細節(jié)。

在這種情況下，有時可能需要創(chuàng)建多種類型的模擬-一種實現(xiàn)IHistoryView和IViewPart的模擬-盡管API并未指出所有這些。 Mockito通過鮮為人知的MockSettings#extraInterfaces模擬配置功能簡化了此過程。 以下代碼段顯示了如何使用extraInterfaces修復上述示例的測試。

@Test public void testConstructor() {Foo mock = mock( Foo.class,withSettings().extraInterfaces( Runnable.class ) );// the mock now supports the cast to runnableBar bar = new Bar( mock );[...] }

使用withSettings的方法調(diào)用會創(chuàng)建一個新的MockSettings實例，并使用其他Runnable類型MockSettings進行配置。 生成的Foo模擬實例同時實現(xiàn)Foo和Runnable 。 現(xiàn)在測試通過了。

但是請記住，盡管在這篇文章中使用額外接口的動機似乎是合理的，但要強調(diào)的是，在實際使用此功能之前，您應該三思而后行。 或者如文檔所述，“如果您碰巧經(jīng)常使用它，請確保您確實在編寫簡單，干凈且可讀的代碼。” 粗心地使用它絕對是一個預定的突破點。

翻譯自: https://www.javacodegeeks.com/2014/03/what-are-mockito-extra-interfaces.html

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結

以上是生活随笔為你收集整理的什么是Mockito Extra接口？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。