mockito接口

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

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

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

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類視為需要某種實現的框架代碼。 由于參數類型Foo不能反映這種期望，因此將Foo模擬傳遞給Bar的構造函數將導致測試失敗，并帶有ClassCastException 。

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

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

在這種情況下，有時可能需要創建多種類型的模擬程序-一種實現IHistoryView和IViewPart的模擬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的方法調用會創建一個新的MockSettings實例，并使用其他Runnable類型MockSettings進行配置。 生成的Foo模擬實例同時實現Foo和Runnable 。 現在測試通過了。

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

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

mockito接口

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。