測試驅動開發

tdd,敏捷程式設計中乙個成功的個人實踐。

重第一次接觸到在工作中使用這個實踐，到現在已經過去半年了，有不少的優點，以及一些個人感覺不舒服的地方。

我們先來簡單的說說什麼是tdd:

三條定律，以及f.i.r.s.t五個原則。下面的定義是重別處拷貝的：

這就是tdd的靈魂思想（這都歸功於tim）：

＃1. bob大叔的三條定律

* 沒有測試之前不要寫任何功能**

* 只編寫恰好能夠體現乙個失敗情況的測試**

* 只編寫恰好能通過測試的功能**

＃2. first原則

* fast: 測試要非常快，每秒能執行幾百或幾千個

* isolated：測試應能夠清楚的隔離乙個失敗

* repeatable：測試應可重複執行，且每次都以同樣的方式成功或失敗

* self-verifying：測試要無歧義的表達成功或失敗

* timely：頻繁、小規模的修改**

寫程式**的時候，一開始我完全的遵循三大定律。

先說說這樣帶來的好處，

1.所有的**都是以測試為基礎的，所有的方法都被呼叫到，命名也很好，畢竟是在寫測試的時候呼叫的，很明確的知道這段**需要實現什麼功能。

2.所有的**測試覆蓋率基本超過95%，

3.**短小，功能明確，避免了不少貼上複製的方法，使用tdd的時候你會不自覺的主動抽取相同**的函式，這個很奇怪。

4.更加明確我們需要實現的功能，每乙個測試都是一段功能的實現，只有分析出需要的功能才會有乙個測試，才會有乙個失敗，才會有一段修改或者新加的**。

使用測試驅動開發的時候很多時候，我們需要認真的思考，我們是不是完全作到了所有的測試，我們所有的功能是不是都已經實現了，有沒有一些基本測試沒有作到。

不舒服的地方，因為每乙個測試一段**，我們的每乙個測試其實要求的是乙個明確的返回，所以我們可以寫出欺騙的**，呵呵：）。

例如：我們有乙個向右轉的**，我們第乙個測試是我們面對東方，向右轉，那我們面南

我們的函式是 tnright();

public void tnright()

這段**的測試可以跑過了，可實際上這不是我們要的**，我們不得不再加乙個測試，你面南，向右轉。

這種小步的向前跑動，讓我們十分的難受。

tdd讓我們可以自由發揮的**，受到了限制，我們不得不按照乙個平穩的速度前進，讓人十分不不爽。

還有，在我們寫完測試準備優化**時，發現**中有個時候明顯存在乙個錯誤，需要增加乙個條件（這中情況是因為測試考慮不全造成），可是我們不能直接加，我們需要編寫乙個失敗的測試，然後修改**，這種時候，讓人心裡洋洋的，不舒服。

以前我們可是分析完功能後一口氣寫上幾個類，十多個函式，上百行**，那種舒服爽快的感覺，沒有了。

可是我還是堅持使用tdd,因為所有的**都有測試，它保證了所有的基本功能的實現都是可靠的，更加深入的理解功能，分析功能。無論以後**如何變化，我都知道，那些基本功能需要實現的功能都有測試可以保證，不會出現丟失。