posman mocks

jmock作者撰寫的有關模擬框架的優秀論文 。 本文寫于18年前的2004年，但其中有許多構建可維護軟件系統的技巧。

在這篇文章中，我將重點介紹本文中的關鍵思想，但建議您閱讀本文以獲取有關模擬和編程實踐的重要思想。

模擬對象是測試驅動開發的擴展。

當我們開始考慮首先編寫測試時，模擬對象可能會很有用，因為它可以模擬仍未開發的零件。 認為是構建原型系統的更好方法。

模擬對象作為一種將測試與第三方庫隔離的技術不太有趣。

這是關于模擬的普遍誤解，我已經使用模擬看到/編寫了許多代碼。 這確實是來自模擬框架作者的大開眼界的事實。

寫作測試是設計活動

確實如此，但是作為工程師，我們花了很多時間放棄編寫測試的最佳部分。 由測試驅動的設計還提供了有關實際問題的見解，并導致了
發明，因為開發人員必須認真思考問題并避免過度設計

耦合與內聚

當我們開始布線測試時，它為我們做出的耦合和內聚決策提供了很好的思路。 好的軟件將具有低耦合和高凝聚力。 這也導致任務的功能分解。

井設計系統的另一個好處是它沒有Law_of_Demeter ，這是不經意間引入系統的常見問題之一。 許多微服務都遭受這種反模式的困擾。

需要驅動的發展

由于模擬需要顯式的代碼/設置，因此它來自測試用例的需求/需求。 您不必根據預測會在6個月后需要某些功能進行編碼，因此可以專注于客戶需求。 測試結果產生的所有接口都狹窄且適合目的。 這種類型的開發也稱為自頂向下開發。

紙報價

“”” 我們發現需求驅動型開發有助于我們專注于手頭的需求并開發一致的對象。 “””

按組成編程

測試優先方法允許您考慮組件的可組合性，每件事都作為構造函數參數或方法參數傳遞。

一旦使用這樣的設計原則構建系統，就很容易測試/更換系統的一部分。 模擬對象允許考慮可組合性，以便模擬系統的某些部分。

模擬測試變得太復雜

論文中的一項觀察談到了模擬測試的復雜性。 如果系統設計較弱，那么模擬將很困難且很復雜。 它確實放大了問題，例如耦合，關注點分離。 我認為這是最好的使用模擬對象來獲取設計反饋并像激勵器一樣使用它來使系統變得更好的方法。

不要在模擬中添加行為

根據論文，我們絕不應在存根中添加行為，以防萬一如果您有這樣做的誘惑，那么這是責任錯位的跡象。

如果您喜歡該職位，那么您可以在Twitter上關注我，以獲取有關我撰寫的隨機內容的通知。

翻譯自: https://www.javacodegeeks.com/2019/08/need-driven-software-development-using-mocks.html

posman mocks

總結

以上是生活随笔為你收集整理的posman mocks_使用Mocks进行需求驱动的软件开发的全部內容，希望文章能夠幫你解決所遇到的問題。

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