與未開發的專案相比，維護專案並不有趣，但可以肯定的是，此專案提供了大部分內容。 這個星期我沒有檢查生產**，而是測試了。 在測試中看到的內容揭示了生產**本身的大部分編寫方式。 這是一種以更少的風險使事情變得更好的方法。
起初，我只想刪除盡可能多的powermock使用。 然後我發現大多數mockito間諜都是不必要的。 然後我發現mockito模擬是在同一檔案中以3種不同的方式初始化的。 然後用法都given()和when()在同乙個班級，然後用法when()和doreturn()在同一類......而且很多可以改進的更多領域。
在本文中，我將限制自己總結一下在測試類中初始化模擬的3種方法：選擇並選擇最喜歡的一種，但請在您的類中堅持使用（如果不是您的專案）。 一致性是可維護性的struts之一。
單元測試是軟體質量的重要基礎（但不是唯一的基礎！）。 由於物件導向的設計是使多個元件各自承擔職責，因此確保每個元件以適當的方式執行其任務至關重要。 因此，我們必須使用已知的輸入來輸入元件，並檢查輸出的有效性。 因此，孤立地測試元件需要一種方法來用我們控制範圍內的輸入提供者和輸出接收者替換依賴項。 mockito是乙個這樣的框架（可以幫助您實現）。
首先，可以使用不同的方式來建立這些模擬（我將使用mockito措辭代替標準方式 ）。
第一種也是最直接的方法是使用mockito的mock()靜態方法。
public
class
footest
@test
public
void
test_foo
()}
它可能是最冗長的，但也是最容易理解的，因為api非常明確。 另外，它不依賴於測試框架。 您可能會嘲笑不利的一面是，如果您有大量依賴關係，則需要乙個乙個地初始化它們-但是也許有這麼高的依賴關係表明設計不好？
第二個選項旨在解決此問題（呼叫次數，而不是設計...）。 它用乙個模擬所有必需屬性的單個呼叫替換所有方法呼叫。 為了確定哪個屬性應該是模擬的，必須使用@mock注釋。
public
class
footest
@test
public
void
test_foo
()}
在這裡，將2個mockito.mock（）呼叫（或更多）替換為單個呼叫。 不利的一面是，必須將區域性變數移至屬性，以使mockito注入模擬。 此外，您必須了解initmocks()方法的工作方式。
最後乙個選項用initmocks()替換顯式的initmocks()呼叫。
@runwith
(mockitojunitrunner
.class
)public
class
footest
}
此選項減輕了編寫單個方法呼叫的麻煩。 但是它具有選項2的缺點，此外，它還可以將您繫結到junit，而沒有其他替代方法，例如testng。
作為維護者，我的偏好按降序排列：
顯式方法呼叫
因為它們是最明確的，因此可讀性強
initmocks
因為它可能掩蓋了您有太多依賴關係的事實......並且不得不用屬性替換區域性變數很糟糕
亞軍 但是最重要的一點是，無論您選擇什麼選項，都必須在同乙個類中堅持使用-如果不是同乙個專案。 沒有什麼比缺乏一致性使**更難以閱讀了。
翻譯自:
mockito初始化引數 初始化Mockito模擬
mockito初始化引數 與未開發的專案相比，維護專案並不有趣，但可以肯定的是，此專案提供了大部分內容。這個星期我沒有檢查生產 而是檢查了測試。在測試中看到的內容揭示了生產 本身是如何編寫的。這是一種以更少的風險使事情變得更好的方法。起初，我只想刪除盡可能多的powermock使用。然後我發現大多數...
初始化 指定初始化
id alloc 物件的誕生過程，主要是從作業系統獲得一塊足夠大的記憶體，以存放該類的全部例項變數，並將其指定為存放記憶體物件的實力變數的位置。alloc方法同時將這塊記憶體全部設定為0。結果是 bool變數初始化為no,所有的int型別變數為0,float變數為0.0，所有的指標為nil.obje...
初始化 1 預設初始化 列表初始化
初始化的基本概念 事實 初始化和賦值是兩個完全不同的操作。初始化，是建立變數時賦予其乙個初始值。賦值，是把物件的當前值擦除，用乙個新值代替。列表初始化 p39 作為c 11新標準的一部分，用花括號 來初始化變數得到了全面應用。出於某些原因，這種初始化的方式叫做列表初始化。現在，無論是初始化物件還是某...