讀
TDD
的總結
讀完TDD（測試驅動開發），發現其中主要就是在反復說了這么兩件事情（也就是兩個簡單的規則）：一、在寫任何代碼之前，寫一個會失敗的自動測試程序，即單元測試；二、消除重復設計，優化設計結構，即重構。整本書都圍繞著這兩個規則來進行說明，告訴讀者到底要如何這樣做？又如何分階段應用這些規則？這兩條簡單的規則可以運用多深？
第一部分通過一個簡單的實例來告訴讀者如何使用TDD，如何反復通過“不可運行/可運行/重構/不可運行/可運行/重構”來進行開發；第二部分告訴讀者如何使用單元測試，怎樣組織單元測試；第三部分則是將TDD分解成較小的步驟來進行詳細說明，根據我對本書的理解，我認為需要完全將TDD運用到日常的開發行為中，則要按照以下非常細小的步驟進行：
1.??????
獲得任務。即項目經理安排的任務。任務往往不止一項。將它們寫入周工作計劃表或者月工作計劃表。
2.??????
選擇任務。每天開始工作之前，將今天將要解決的問題寫入工作計劃列表。并選擇自己最有把握完成的任務作為當前任務。
3.??????
分析并分解任務。將當前任務分解成一個個相對簡單的問題，分解的問題最好是能在十多分鐘之內能完成，并將它們寫入工作列表。如：若要實現多幣種相加，則可以分解為：實現相同幣種之間的相加，不同幣種之間的互換，最后才能實現不同幣種之間的相加。
4.??????
寫測試列表。將分解后的問題所對應的測試寫入測試列表。
5.??????
選擇測試。從測試列表中選擇自己認為最有把握實現的一項。如：“同幣種相加”對我來說是最有把握實現的一項，因此我最先來實現它，即先從它的測試程序開始編寫。
6.??????
編寫測試數據。寫一個容易讓人理解的必須實現的測試數據列表，盡量使用顯然數據。如：用
String
表示
IP
地址
"255.255.255.255"
轉換為
int
，在我們寫測試數據時應這樣寫：
(255 << 24) + (255 << 16) + (255 << 8) + 255
，而不是寫“
-1
”。
7.??????
編寫測試。選擇一項最容易讓測試通過的測試數據加入測試方法。斷言優先，然后加入為了讓斷言通過編譯的一切準備條件。
8.??????
運行測試，不可運行狀態。
9.??????
編寫方法注釋，把所有想到的該方法要實現的功能寫上。
10.??
編寫功能代碼，使之達到可運行狀態。
11.??
重構，消除重復設計。
12.??
往測試方法中增加一個新的小測試。
13.??
運行測試，不可運行狀態。
14.??
修改功能代碼，使之達到可運行狀態。
15.??
重構。消除重復設計。
16.??
重復
12-15
。
17.??
當無論如何也不能讓該測試通過的時候，認真想一想是不是哪里出大問題了，如果實在想不出來的話，就將現有代碼扔掉，重新開始。
18.??
所有測試都運行通過之后，仔細檢查所有代碼，看是否還有值得重構的地方，并重構。
19.??
提交
(check in)
。
20.??
再選擇測試列表中的下一個測試。重復以上步驟。
21.??
當一天的工作結束時，若有某個任務未完成，則留下一個不完整測試，以便于次日能迅速回憶起當時寫該代碼時的想法，并接著寫下去。
?
?
?
以下是我對本書中某些觀點的看法：
1.
????
本書旨在培訓我們具有按照極小的步驟進行開發，并尋找Bug的能力，并不是說一定要按如此小的步驟進行。
2.
????
書中所反復強調的“測試優先”，“斷言優先”是說在功能代碼之前先寫測試，先寫斷言，可是反過頭來，以第一個測試來說：
public void testMutiplication()
{
Dollar five = new Dollar(5);
five.times(2);
assertEquals(10,five.amount);
}
就這個測試來說，其實作者在寫測試的時候也想了很多的問題：把這個測試放哪？總不可能拿記事本來寫吧！至少該給這個測試方法先建立一個測試類吧！同樣在建立這個測試類的時候，是不是也在想著為該類命什么樣的名？再進一步，我要寫測試方法，在為測試方法命名的時候實際上也是在為我們所要寫的方法命名，不是么？因此，我覺得，在我還沒有達到Kent Beck的水平之前，我還是會在寫測試之前先想一想即將要編寫的方法應歸于哪個類，并先將該類創建好，再把下一步要編寫的方法寫好（當然此時肯定也是一個空方法），同時把自己所能想到的方法將要實現的功能（可以是比較粗略的）全部寫入方法注釋中，此時的注釋可以是比較隨意的，因為在把方法寫完之后還要進行重構嘛！然后按照注釋中的功能來編寫一個一個的測試方法并完善功能代碼。
3.
????
如果按照本書所說的，開發過程中幾乎沒有事先的設計，因為作者認為良好的設計會在重構中逐漸浮出水面的。但是我很清楚，我不是Kent Beck，如果沒有事先設計的話，以我現在的水平，重構時的工作量一定會非常大；因此如果在寫代碼之前花一定的時間設計一下代碼結構，可以在一定程度上減小重構時的工作量。并且我認為良好的事先設計會為重構工作減少很大的工作量，當然事先設計也不應該占有太多的時間，否則，還不如先寫完之后慢慢來重構。
4.
????
書中所說的關注當前工作這一點非常好，因為在現實工作中，常常會因為想到與當前工作相關的事情可能會比較多，而往往我們會丟下手上的工作，先去完成另外一項工作，可是等回到剛才丟下的工作前時又要花很長的一段時間來回憶當時的情形。因此，我們應該學習書中的方法，把新想法記錄下來，等完成當前工作后再去考慮。也許有些時候會出現這種情況，如果另外一件事情未完成，當前工作無法進行的情況不得不打斷當前工作，那就不得不將注意力全部轉移到另外一件事情上去。但是，如果這種打斷出現多次的時候，就應該認真思考自己的分析問題的粒度是不是太大了，然后重新去分解問題。等問題分析到可以不依賴未編寫過的方法時再繼續工作也不遲。這樣只會提高工作效率和自信心。否則，不停地從當前工作中跳出，不僅為影響工作效率，而且會影響自信心，為什么還有這么多沒有完成呢？因為在你不斷地跳出當前工作后，你就會留下一個個未完成的工作。你的腦子里就會想著還有多少個未完成的工作在等著自己去完成。
5.
????
留下一個不完整測試是在編程期間結束工作的最好辦法。因為當測試運行時沒出現綠色狀態條時，會很容易找到明顯的地方重新開始。這一點實現起來可能有點困難，但是卻是一個非常有效的辦法，當工作任務繁多的時候常常會忘記昨天做到哪了，今天該從哪做起。
6.
????
當編寫功能代碼時，為了讓測試通過可以采取的措施有：顯明實現，偽實現，三角法，從一到多。當自己讓該測試通過有把握的時候，即使用顯明實現；若在顯明實現的過程中，無法達到可運行狀態，則返回到之前的可運行狀態，采用偽實現的方法使測試達到可運行狀態；當需要為集合編寫測試的時候，采用從一到多的方法。如：數組求和則可以先測試該數組中只有一個元素，再逐漸增加元素進行測試。
7.
????
相互獨立的測試。即每個測試之間必須互不干擾。如果一個測試失敗必須只對應一個問題；兩個失敗就對應兩個問題。測試之間都不依賴與運行順序，一個測試不要因為前面的測試不存在而失敗。這一點實現起來其實也相當的困難，因為當一個底層函數的測試失敗時，其上層函數（即調用了它的那些函數）的測試程序都可能會失敗，因此很難做到一個失敗的測試對應一個問題。
8.
????
當在編寫代碼時，當第一次準備使用某個包內的某項新功能時，為其編寫測試，即學習測試?？此欠駶M足我們期望的要求。并且必須在其符合我們的期望要求時我們才可以在程序中使用它。
9.
????
當每新建一個包時，即新建一個AllTests類用于測試該包中所有測試類。在每寫一個測試類時，先將public static Test suite()寫好，并把該測試類加入到包中的AllTests中，隨時確保包AllTests中包含了包中的所有測試程序。
10.
?
需要重點掌握的重構方法（即常用的重構）有：重命名，提取方法，添加參數，刪除參數，方法內聯，提煉方法對象，消除臨時變量，提取匿名類，分離內部類等等。
11.
?
在我們工作的過程中，很多時候會遇到一些很困難的問題，在反反復復思考許多遍還是想不到解決的辦法，往往這樣的情況是我們的思維陷入了錯誤的陷阱里，在這個時候我們可以選擇休息一會，喝一杯茶，走動一下。拋開那些剛才所做的事情。如果在休息了多次之后還沒有想到解決方案，就扔掉這些代碼，重新開始。
?
?
|