前言
最近有幸跟隨資深ThoughtWorks諮詢師熊節老師一塊兒學習測試驅動設計，通過短暫的十幾天培訓，對測試驅動設計的基本原則、實踐模式、技巧有了一點點初步的認識。 編程
在此以前，常常自嘲我經歷的公司實踐也彷佛是TDD， 這種實踐每每都是由測試工程師來驅動開發者完成bug的修改，雖然也是測試來驅動開發，可是卻與真正的TDD截然不同。工具
什麼是TDD
post
測試驅動開發（英語：Test-driven development，縮寫爲TDD）是一種軟件開發過程當中的應用方法，由極限編程中倡導，以其倡導先寫測試程序，而後編碼實現其功能得名。測試驅動開發始於20世紀90年代。測試驅動開發的目的是取得快速反饋並使用「illustrate the main line」方法來構建程序。
測試驅動開發是戴兩頂帽子思考的開發方式：先戴上實現功能的帽子，在測試的輔助下，快速實現其功能；再戴上重構的帽子，在測試的保護下，經過去除冗餘的代碼，提升代碼質量。測試驅動着整個開發過程：首先，驅動代碼的設計和功能的實現；其後，驅動代碼的再設計和重構。
測試驅動開發也是國外許多優秀開發者向開發者們推薦的一種廣泛適用的開發模式，而在熊節老師的培訓課程中，他時刻在向開發者灌輸來自TDD的三條原則，要求咱們的編寫生產代碼前，必定應該先編寫單元測試。單元測試
定律一：在編寫不能經過的單元測試前，不可編寫生產代碼。
定律二：只可編寫恰好沒法經過的單元測試，不能編譯也算不經過。
定律三：只可編寫恰好足以經過當前失敗測試的生產代碼。
簡單實踐
在我以前的編碼實踐過程當中，老是習慣梳理一遍邏輯後，在根據項目的實際狀況對代碼進行重構，而隨着我自覺得掌握了單元測試的技巧以後，就開始把邏輯代碼往單元測試上套，致使這樣的單元測試實際上並不是爲了實現測試，而僅僅只是程序的入口而已。學習
若是使用TDD的方法，則須要首先規劃須要實現的目標，而後再定義測試方法和測試須要實現的邏輯。測試
例如，代碼大概是這樣的：ui
個人目標是實現對Schema對象的解析，測試類採用SchemaUnitTest，並採用「should_xxx_when_xxx」的命名方式，定義了測試方法「should_return_true_when_bool」，而後定義一個Schemas的類，再定義其須要實現的需求（斷言），以及需求的實現。編碼
對單元測試方法的命名，不一樣的書籍有不一樣的命名方法，在這個項目實踐中，採用的是should命名方法，而在以前看過的《單元測試的藝術》一書中，使用的is_when_return_xxx的方式，這二者只是命名方法的不一樣，本質上沒有任何區別；使用xunit和mstest實際上也沒有太多區別。spa
此時，這個定義的方法GetParameter是未實現的，因此會進入一個「紅-綠-重構」的工做流程。設計
1）編寫一個會失敗的測試，以證實產品中代碼或功能的缺失。編寫代碼時，要假設產品代碼已經能工做了，這樣測試的失敗就說明產品代碼中有缺陷。例如我定義的GetParameter方法使用xunit進行測試會提示失敗， 只有在添加須要的代碼後，編譯才能經過。
2）編寫符合測試預期的產品代碼，使測試經過，產品代碼應該儘可能簡單。
3）重構代碼。若是測試經過了，你就能夠編寫下一個單元測試，或者重構，消除異味或提升代碼可讀性。
最終，我完成了一個這樣的方法。（即使是這樣的代碼，依然有許多能夠進一步提高的空間。）
顯然這是一個邏輯很是簡單的代碼，可是若是採用全鍵盤操做，不使用鼠標來完成，仍然耗費了我很多時間，這個過程當中，也讓我對Visual Studio的快捷鍵操做更加熟練。
測試的不一樣階段
在咱們的產品研發過程當中，常常遇到如下三種不一樣形式的測試
- 端到端測試：端到端測試側重於軟件功能應用層面的測試，主要使用人工或自動化的形式對用戶界面進行測試。每每須要覆蓋系統的各個功能，須要耗費的人力物力較大。
- 服務測試：主要集中在服務接口層的測試，能夠經過PostMan等測試工具對接口的穩定性和可用性進行測試。側重於接口行爲實現。
- 單元測試：針對代碼層面，例如單個方法或單個類實現的測試。屬於白盒測試的一種。
三種測試從上到下實施的容易程度遞增，可是測試效果遞減。端到端測試最費時費力，可是經過測試後咱們對系統最有信心。單元測試最容易實施，效率也最高，可是測試後不能保證整個系統沒有問題。
在咱們的項目實踐中，更多的採用的依然是端到端測試的模式，彷佛只有經過測試者的人肉測試，才能讓咱們的代碼更加使人滿意。
單元測試事實上極少在咱們的項目中獲得實踐，其主要緣由大概是由於要掌握單元測試方法，自己須要對開發者的主觀能動性提出了更高的要求，可是996開發者...太容易內卷化了。
總結
寫好單元測試歷來就是技術活，有一段時間過度在乎理論概念和工具的用法，忽略了實踐，因此實際上看了好幾本書，依然不知道如何寫單元測試，此次參與了培訓，終於摸到了一點點影子。
現階段我大概能夠這樣作來逐步提升本身的技能水平：
- 一、小步快跑，注意節奏：不要過分在乎某個需求的快速實現，而是編寫可以在五分鐘內快速完成的代碼，並確保其經過。代碼行控制在五行之內，代碼的縮進層次，控制在兩到三層。
- 二、練習，練習，再練習：寫代碼歷來不是一件容易的事情，按照一萬小時定律的說法，若是期望幾天就熟練掌握顯然不太現實，將來須要更加積極的練習，才能真正掌握。
- 多思考、努力寫好代碼：寫幾行代碼其實並不難，難的是寫高質量的代碼。不要急於代碼實現，要多思考上下文邏輯，讓代碼更加優美。
參考資料：
