這個系列來自我讀《Test-Driven Development in Microsoft .NET》這本書的一些內容，以及一些自己的體會。

　　1、什么是測試驅動開發？

　　可以用下面的兩句話來定義。

• 　　在你已經寫好一個測試失敗的自動化測試用例之前，絕不寫一行代碼。
• 　　消除代碼重復。

　　第一句話很好理解，就是在寫代碼之前，先寫一些測試失敗的自動化腳本，測試肯定是失敗的，因為沒有任何實現。因為測試包含代碼必須滿足和實現的需求。如果沒有需求，就不需要實現任何功能。這條可以防止我們實現沒有測試和不需要實現的功能。

　　但是我還是有一點疑問，就是如果一行代碼都不寫，連接口沒有，自動化腳本又測試什么呢？也只能寫一寫手動測試腳本，功能性的測試腳本。針對具體實現的自動化腳本，也還是要等接口出來才可以寫吧，你們說呢？

　　第二點是說在應用中不應該有重復的代碼。代碼重復是一種典型的不良軟件設計，會導致矛盾問題。如果有代碼重復，在看見的時候，程序員就應該消除它。

　　2、簡單的設計

　　因為測試覆蓋了需求，所以在寫代碼的時候，你的工作就是不多不少的滿足需求。每個人都理解“不少”（因為少了軟件沒有辦法工作了），但是不是每個人都理解“不多”。

　　“不多”是什么意思呢？想象回到有人讓你在現有系統上添加功能的時候，然后你說“沒有問題，在之前我就已經想到會發生這個了，我已經加入了這個功能的代碼”。你被看做是英雄，因為你預料到了這個需求，并且在解決方案中已經實現了它。

　　想一下在你為了額外的功能增加復雜性的時候，抽象類，等等，那些沒有人讓你實現的功能。這些額外的代碼必須隨著那些使用中的代碼一起維護。事實上，維護這個軟件的負擔在加重，因為它超過了實際的適用范圍。因此你需要為不多、不少而奮斗，可以參考下面:

• 　　代碼滿足了當前客戶的要求。
• 　　代碼通過了所有的測試。
• 　　代碼做了需要做的每一件事。
• 　　代碼的類數量最少。
• 　　代碼保持了最少數量的方法。

　　優先級最高的就是：代碼滿足了當前客戶的要求。在你滿足了適當的需求之后，下一個高優先級的是：代碼通過了全部的測試。其次就是其他的了。

　　有一句話，原文是：

　　You might think that achieving simplicity is an easy process. Think again—it’s often very difficult. However, the simpler the code is, the more resilient it is and the easier it is to modify.

　　我是這么理解的：

　　你一定認為完成這些簡單的事情是一個非常容易的過程。自己想想，通常它很困難。但是，代碼越簡單，它越有彈性，越容易修改。

　　我不知道是不是我理解錯了，還是這句話本身就是錯誤的呢？我不認為代碼越簡單越好，應該保持適度，甚至是應該相對應該復雜一點。如果類最少就是好的，那就寫幾個類好了，每個類幾個方法，方法要少嗎，那就每個方法寫上幾千行。這樣的代碼還能有彈性嗎？還能容易修改嗎？這么說來的話，分層和設計模式是最扯蛋的了，他們會導致很多的類，很多的方法。還有就是設計原則：SRP，單一職責原則，更是要求類的職責要單一，每一個類只應該有一個改變它的理由。這不都是矛盾的嗎？如何理解呢？還是我太極端的理解了書中的意思呢？

　　3、重構

　　重構可以理解為，改進代碼本身，但是不影響功能。重構是TDD的關鍵環節，因為在增加測試的時候，需要重新定義代碼的設計。例如：你在代碼中看到了重復，你就要移除它。如果需要引入復雜性來移除重復，也是正確的，因為是實際需要的，而不是預期設計的。

　　4、紅/綠/重構

　　紅、綠、重構，定義了實現每一個測試的過程。這個過程的目標就是工作在一個小的，可驗證的過程，可以提供及時的反饋。

• 　　編寫測試代碼。
• 　　編譯測試代碼，它肯定會失敗，因為你還沒有寫任何實現的代碼。
• 　　編寫實現的代碼。
• 　　運行測試，觀察測試結果，可能是紅色的。
• 　　使得測試通過。
• 　　運行測試，觀察測試結果，直到變綠。
• 　　重構代碼，消除重復代碼。
• 　　重復上面的過程。

　　這就是著名的紅綠條，不斷的修改代碼，直到進度條變成了綠色。因為，紅色代表沒有通過測試，綠色代表通過了測試。然后再對代碼進行重構，消除代碼中的重復。