測試先行就是我們常說的測試驅動開發（tdd）
測試先行的實踐方式是在接到乙個新功能的時候，先寫乙個測試，這個測試一定會失敗，然後編寫**使得測試成功，然後再寫下乙個測試，有點像是填坑的方式進行開發。
傳統的開發方式是：設計-開發-測試 如此往復
測試先行的開發方式是：測試-**-重構 如此往復
下圖指示了設計先行的開發方法：
我們在實際開發中，通常會犯的兩個錯誤就是：
只使用最少的**實現正向的邏輯，漏掉或完全不考慮異常情況
再開發完主要功能之後，考慮到太多的異常情況，使得異常情況的處理變成補窟窿，最終得到的結果與原設計差別巨大。
使用測試先行的方法，在編寫測試的過程中，就通過使用者故事設計出各種異常情況的測試，「強迫」開發人員在編碼的時候考慮異常情況，再者，將異常情況代入整體的設計，一定可以讓**更加簡潔，降低**的複雜性。
這種開發方式會潛移默化的改變我們的程式設計風格，本質上說：測試幫助我們針對實際使用來塑造設計測試先行的單元測試不僅是在保護回歸，而且是在幫助設計。在編寫**之前就指出**的期望行為，從而在驗證實現之前先驗證設計是否可行。
我們學習單元測試的目的都是相信單元測試能夠作為我們程式的安全網，然而在不經意間我們會學會使用測試表達我們的思考過程，設計過程。
編寫測試最大的價值不在於結果，而在於編寫過程中的學習。在上一節中，我們看到隨著測試增多，測試價值的曲線，如果我們使用測試先行的設計方法，我們就應該需要關注到將測試作為設計工具，我們的收穫曲線，而這種收穫是測試最大的價值。
如果我們僅僅編寫單元測試而不使用測試先行的方法，我們就等於將圖中虛線的價值拋棄了，也就是說開發者沒有使用測試驅動開發（tdd）。
將tdd提公升到需求層面就得到了bdd，通過編寫驗收測試，與客戶的積極互動，完善驗收測試，最終給程式開發人員輸出最貼合使用者期望的需求描述。
在本系列中，我們不著重講bdd，而是站在技術的角度來講單元測試。
編寫優秀的單元測試（五）編寫測試
準備 執行 斷言 arrange act assert 這個流程是 準備用於測試的物件 觸發執行 對輸出進行斷言 怎麼寫測試是個問題，寫多少測試，也一直是個問題。這裡我們給出乙個建議 檢查行為，而非實現。具體來說，我們應該跳出具體的實現，把關注點放在我們期望類有怎樣的行為上，不應該讓實現主導測試，而...
編寫優秀的單元測試（六）編寫可讀的測試
網上有乙個段子，說程式設計師最煩做的兩件事情，乙個是寫文件，乙個是寫注釋。程式設計師最煩別人不做的兩件事情，乙個是不寫文件，乙個是不寫注釋。這裡提到了程式開發裡面的乙個最基本的事實 讀 比寫 難。這也是我們經常在工作中重構的原因，因為我們經常覺得有看那些 的時間，我都重寫一遍了。說這些是為了告訴我們...
單元測試 單元測試編寫的原則
公司要求提公升單元測試的質量，其中我作為方案和推動的主導，對開發過程中的單元測試，有了一些思考和總結 單元測試編寫的目的，是面向計算機特性的，基於函式的in out，所以單元測試的好幫手就是斷言，通過不斷的構造輸出並對結果進行斷言，我們就可以針對乙個物件以及它的函式，構建出充足的用例去包裹它，以期望...