我很好奇你們中有多少人把你的日常開發過程中的對象（JMock，NMock，RhinoMocks和框架一起）的嘲諷結合起來。你有什麼經驗？廣泛使用對象嘲笑嗎？
您知道，我在GIS（地理信息系統）平臺之上開發，其中大部分工作涉及某種處理數據的方式。由於其數據對象模型非常複雜（許多類和接口，都是基於COM的），所以模擬也很困難和麻煩。在這種情況下，編寫測試套件時嘲笑會產生很大的開銷。我想知道是否有人處於類似的情況，或者只是，如何嘲笑（無論你處於何種情況）爲你工作。
在我最近開發的一個項目中，我們在單元測試方法中廣泛使用了模擬對象。該項目是100％Java和中等規模（約100,000行非評論代碼）。這是一個基於Swing的桌面應用程序 - 我們發現測試用戶界面邏輯的唯一有效方法是通過MVC變體設計，它允許我們使用模擬對象替代實際的Swing用戶界面類進行自動化測試。我們還在測試數據訪問層（Hibernate/DAOs）時廣泛地使用了嘲諷。
在用戶界面使用中，Mocks很容易且直接地構建。而應用程序（Fowler Passive View）的設計很容易引入mock。測試數據訪問層時使用的模擬不是這種情況。但我可以說這顯然是值得的。事實上，大部分「努力」都着眼於提出一種可重複使用的解決方案，最大限度地減少開發人員爲創建每個模擬所做的工作。我建議花時間挖掘並發現適合您情況的方法，以便您輕鬆地模擬GIS數據層。那 - 或者只是手動模擬每個課程。無論哪種方式運行依靠模擬的自動單元測試的能力是值得的...
在我的情況嘲諷工作真的很好。但是我使用Python，它非常動態，它使涉及測試的許多事情變得更加容易。
在像你這樣的情況下，當應用程序主要是數據驅動的（據我所知），嘲笑可能沒有那麼有用。僅僅傳遞數據並觀看它就足以進行測試。我只是確保應用程序是模塊化足夠，所以這種方法可以適用於合理的小組件。
嘲笑在某些項目中很有用。但是，有時嘲笑非常耗時且投資回報率很低。
試圖測試Sharepoint似乎嘲笑是唯一的方法，只有typemock會讓你嘲笑密封類。
嘲笑在我的情況下使用非常廣泛。嘲笑通常用於具有外部依賴性的類，例如網絡，數據庫，文件系統。如果不使用嘲笑，任何這些都會在測試中引入片狀。
如果由於需要填充大量假數據而發現編寫代價昂貴的模擬，可以將一些預填充的數據對象設置爲常量，並在測試中使用它們或稍微修改的副本。如果這樣的數據對象具有外部依賴關係，那麼可能會重構它，以便分離兩個關注點。
Dave Bouman開始嘗試創建一個Mock社區庫，以用於ArcObjects相關單元測試。他的博客，這個svn庫有相關的單元測試GIS系統巨大的信息
http://blog.davebouwman.net/CategoryView,category,Unit%2BTesting.aspx
http://svn2.assembla.com/svn/arcdeveloper/TestingUtilities/trunk/