很多情況下，**需要與外部依賴打交道，如乙個rest位址，資料庫鏈結、外部io等；這些依賴有些速度過慢、有些不夠穩定，不符合單元測試要求的快速、可重複等原則性要求，因此引入了mock物件這一概念。與mock相關的還有stub這個單詞。
一般來說，在編寫stub之後，需要將其注入依賴物件中，也即依賴注入（di），框架上有spring di和google guice等。
為了使得測試更加容易，有時需要修改**，如將依賴以成員變數的形式傳入被測類中，如：
public class addressretrieverpublic address retrieve(double latitude, double longitude) throws ioexception, parseexception
}
但不僅限於建構函式，還可以通過set方法或其他依賴注入框架實現。
如這個樁：
這個樁接受任何uri即可返回對應的結果，沒有對輸入進行判斷，我們期望的是：在收到預期引數時提供預期的輸入，可以通過在get()方法中加入判斷實現，這樣的通用功能引入mock工具。
when().thenreturn()模式就是mockito設定的常用方式。
di工具有很多，如spring di和google guice，但是moctito內建的di工具也能滿足絕大部分的需要，步驟如下：
下面是示例**：
最後需要注意的是，如果使用了mock，那不是直接測試生產**，而是在於生產**中加了鴻溝，單元測試的正確性依賴於被mock物件的正確性，因此單元測試需要配合端到端的整合測試。
何時應該使用Mock物件？
英文原文 中文原文 在 ode to code 上，k scott allen理性地分析了如何在單元測試中使用mock物件，並分享了他針對mock物件框架使用情況的想法。首先，allen就人們對mock的常見誤解，丟擲了尖銳的意見 我們知道，像與smtp伺服器通訊的物件這樣的資源，是很難在單元測試中...
何時應該使用Mock物件？
英文原文 中文原文 在 ode to code 上，k scott allen理性地分析了如何在單元測試中使用mock物件，並分享了他針對mock物件框架使用情況的想法。首先，allen就人們對mock的常見誤解，丟擲了尖銳的意見 我們知道，像與smtp伺服器通訊的物件這樣的資源，是很難在單元測試中...
使用mock物件乙個舉例
package cn.com.rzx.test public class a public string testmethod string str package cn.com.rzx.test public class b implements binte nce package cn.com....