一直都對TDD很感興趣，也很向往Test Driven 的開發方式，雖然在網絡上看過大大小小的很多文章,
但感覺還是不是很深刻，希望通過這本書，能讓我在對TDD的認識上更上一層樓.也希望能在今后的在工作中應用它.
同時，記錄一下閱讀該書時的一些總結及想法.也希望能和大家交流.
一.概述:
該書主要講了四部分.
(1) 介紹了TDD相關背景知識(TDD、Refactoring、Programing by Intention)
(2) 介紹了相關工具與技術(Junit、Mock)
(3) 詳細介紹了一個采用TDD開發的GUI項目
(4) 闡述了xUnit相關框架
二. 總結
任何一本XP或TDD的書上都會提到這些概念，這里就個人的理解總結一下
1. 為什么要TDD?
任何人從程序員到用戶，都明白測試有益,但為什么發布的軟件總是存在bug，讓我們先來看看傳統測試方法帶來的弊端:
a.測試常常時在code完后編寫，或者某些(P)programer一完成編碼，就轉而繼續從事其他項目開發.當P不在與某個程序同呼吸、共命運時，也許再處理其中的問題是要花更多的時間和精力的.
b.測試不是由編寫代碼的人完成，因此，再他們沒有充分理解代碼時，是很難編寫出充分的測試的.
c.測試是依照文檔編寫的，文檔和代碼同步嗎?
d.如果測試不能否自動進行，那它們能被頻繁的、經常的運行嗎?
e.不充分的測試導致的致命問題就是當你修復了一處bug，卻不知道帶來的潛在的更大bug.
2. 什么是TDD?
a.首先編寫測試
當有一項任務要做時候，先編寫出用于測試功能是否符合要求的代碼，然后在編寫足夠讓測試通過的代碼，
接著再編測試、再編代碼......
b.除非存在相關測試，否則不寫任何產品代碼
極限編程的原則就是在相關測試沒有編寫之前，不編寫任何功能代碼.因為系統中的一切必須是可測的.所有的測試代碼
都是你執行重構和集成的先決條件,如果在沒有測試的環境中，你無意修改了部分代碼，你能夠自信的進行重構，集成?
c.由測試來決定需要編寫怎樣的代碼
只編寫讓最新的測試通過的代碼,簡單的說，就是"編寫最簡單但又能工作的代碼(do the simpleest thing that could posibilly work)
d.維護一套詳盡的測試集.
保證你重構和集成的充分條件.同時，你應該用事實、用數據來證明你的代碼是正確的.
關于重構，Martin Fowler 的<Rafactoring>是真正的權威.這里就不具體說了.
3.什么是重構?
在不改變外部行為的條件下,對現有代碼進行修改的過程.
4.何時重構?
重構應在任何需要的時候，重復代碼、代碼意圖不清晰、bad smell.....
5. 意圖導向的編程
XP的核心理念之一，在編寫代碼的時候應該清晰地表明自己地意圖.
遲早會有人閱讀我們的代碼的，任何閱讀代碼的人，包括我們自己，都會在那種拙劣、復雜或含糊不清的情況下產生誤解.
如何編寫意圖清晰明確的代碼完全值得任何程序員去學習.....
a. 名字
(1) 用名詞或名詞短語作為類的名字
如MovieRating,MoveListReader等
(2) 使用形容詞、一般名詞或名詞短語為接口命名.
優先使用形容詞來命名接口，通常以-able,-Aware等結尾，如Runnable,Serializable,以及spring中的xxxAware
(3) 動詞或動詞短語做方法名
(4) 名詞或名詞短語作為變量名.
三 牢騷
這部分純屬于個人的扯談，不過有想法就留念一下吧....呵呵
無論是TDD，還是重構，出發點真的太好了，可能是這些牛人在總結了多少次彎路后的經驗之談.但從目前的情況看，我感覺需要一套完整的測試集很重要,但也正因為如此，現在的測試手段、測試框架越來越多，程序員需要掌握的不僅僅是新技術，好工具，在對測試的理解、重要性以及測試工具的使用上又要花大力氣了.
其實個人比較向往TDD，覺得它應該完全改善了你編程的思維，讓你真正從需求的角度出發,讓你的代碼具有可測性，但這可能只是偶的目標了.
目前，偶的要求不高，覺得能在測試集合完整的情況下，編碼、重構就算是一種享受了.
目前所在的公司，真的很讓人郁悶，大家連測試都不怎么作，還整天鼓吹著Refactoring,上次給Manager寫了一封建議信后，還和我講了很多大道理，不過還算有點效果，雖然case較少，但至少現在開始測試了.
什么時候偶的代碼能成為一件精雕細酌的藝術品,我能成為這個藝術品的藝術家呢?估計只有在dream中了....
唉，中國的軟件,提不成!