測試驅動開發——讓你的代碼更簡潔
原創-
發表時間 2021-02-03
-
閱讀數 7440
-
最后编辑:琦琦 于 2025-05-23 15:46:09
蓋房子時,工人師傅砌牆會先用樁子拉上吊線,以吊線爲基准,以使磚能夠壘的筆直。而測試驅動開發也是如此,先寫一個測試,然後研發過程以此爲基准,只編寫能通過這個測試的功能代碼。
順序顛倒下,先壘磚,再拉吊線看牆面是否筆直,不直的話進行校正。這個過程就像傳統的軟件開發流程,先寫功能代碼,然後進行測試,有錯誤再一點點修改,因此,會嚴重影響研發效率。
測試驅動開發的目標
代碼整潔可用,是測試驅動開發所追求的目標。但有很多因素會妨礙我們得到整潔的代碼,甚至是可用的代碼。
如何實現測試驅動開發?
1. 只有自動測試失敗時,我們才重寫代碼;
2. 消除重複設計,優化設計結構
这两条规则实际上也蕴含了开发过程中所经历的阶段。 测试驱动开发的整个流程正是将目标拆分,先达到“可用”目标,再追求“简洁”目标。
測試驅動開發的流程
1. 首先思考并编写用于定义産品代码 行为的测试
2. 運行測試,發現新增的測試不能通過
3. 編寫適當夠用的代碼
4. 運行測試,直至測試通過
5. 重构代码,以消除重複設計,優化設計結構
6. 運行測試,驗證重構是否引入新的錯誤,直至測試通過且無需再重構
7. 最後重複上述步驟
測試驅動開發其實是戴兩頂帽子思考的開發方式:先戴上實現功能的帽子,在測試的輔助下,快速實現其功能;再戴上重構的帽子,在測試的保護下,通過去除冗余的代碼,提高代碼質量。
測試驅動開發,要求測試可以完全自動化運行,在對代碼進行重構前後,必須運行測試。這有助于編寫簡潔可用和高質量的代碼,能快速響應變化,並加速開發過程。
測試驅動開發的三定律
定律一:在編寫不能通過的單元測試前,不可編寫生産代碼。
測試驅動開發主張“測試先行”,這意味著我們必須先寫單元測試,並且該單元測試必然失敗,才能編寫生産代碼。
定律二:只允許編寫剛好能夠導致失敗的單元測試,編譯失敗也屬于一種失敗。
測試驅動開發鼓勵“簡單設計”,以很小的增量進行開發,遇到設計問題時能夠及時解決,不要期望一個測試能實現多個功能。
定律三:只允許編寫剛好能夠使得失敗的單元測試通過的生産代碼。
簡潔,盡最大可能減少不必要的工作,也是敏捷基本原則之一。要避免盲目編寫將來有可能需要的代碼。
遵循了測試驅動開發的這三條定律,那所有代碼都是可測試的了。“可測試”的另一個詞是“解耦”,爲了單獨測試模塊,必須將其分離,所以測試驅動開發強迫分離模塊,迫使大家創建更好、更少耦合的設計。
Kent Beck最早在其極限編程方法论中,向大家推荐“测试驱动”这一最佳实践。極限編程中所有实践方法并不是独立的,而是相辅相成的。欢迎大家关注極限編程系列往期視頻,了解更多極限編程实践方法。
-
禅道産品
禅道開源版 禅道企業版 禅道旗艦版 禅道IPD版 -
核心功能
産品管理 項目管理 質量管理 效能管理 -
使用文檔
基本版手冊 企業版手冊 旗艦版手冊 IPD版手冊 開發中心手冊 -
幫助中心
积分問答 常見問題 論壇交流 使用視頻 Gitee GitHub -
關于我們
關于我們 禅道軟件 最新動態 禅道活動 -
禅道社區
禅道博客 積分排行 積分商城 禅道書院 -
聯系方式
聯系人:金娟 電話:18562856230 微信:18562856230 Q Q:1826606239北京、上海、深圳分部