tdd，也就是 test driven development--測試驅動開發，其實是一種開發方式的巨大提高。它
提出了一種新的開發方式：以測試為驅動。在此，我仍然想引用乙個曾經看過的thoughtworks的
乙個人的blog中的一句話：「什麼是tdd？tdd就是把你的需求用測試給描述出來。」這句話一下
子讓我明白了tdd的意義，並且被我個人奉為tdd中的經典 :)
歸根到底，tdd的實質仍然是以需求來驅動開發，只是，tdd中把需求進一步寫成了測試，那
就成了測試驅動開發了。
這麼做的好處是什麼？我想至少有以下這麼幾條：
1、你的**是可測試的。
2、你的**完全反應了需求。
3、通過測試驅動，會規範你的**和結構，甚至架構。
不錯，我承認，tdd會帶來成本的提高。因為我們要寫測試，所以必然要花費時間。那麼這部分
的成本誰來買單呢？客戶嗎？這很難，因為畢竟大部分的客戶已經在軟體的本身就和你討價還價
了，你還想讓客戶再為測試來買單？
讓老闆買單？老闆恐怕要為此付出加班費。捨得，還是捨不得？這似乎又變成了乙個哲學的問題。
自己來買單？也就是自己白加班來做這些事。值得，還是不值得？這似乎又是乙個職業態度的
問題。
如果單從理論上，每種買單方式都可以寫厚厚的文字去論證，不過這麼做其實並沒有很大的意
義，我還是從實踐中說起。
就說最近的兩個專案。乙個是公司的移植專案，從乙個專有的framework移植到structs；另乙個
是我幫助朋友做的乙個國內的小專案。第乙個專案，我說了不算；第二個專案，我的意見起主導
作用。
移植專案的團隊中一共有10個人。我使用了selenium這個工具。但因為是移植的專案，所以
tdd的概念也就無從談起。不過，每移植乙個功能之前，我都是先按照舊系統的操作，使用
selenium來編寫測試類。在功能移植完畢之後，我在新系統中去跑我的測試類。
因為需要測試的內容非常多，所以，我的測試方法也是越寫越多，其中不停的重構和修改，也
總結了一些簡單的測試方式。
是的，最開始，我花的時間確實比別人多一點，多多少呢？？乙個測試方法，我相信我用10分
鐘就足夠寫好了。重構？我想1，2個小時足夠了。
而且，我每次修改完乙個功能，我可以執行全部的測試，這樣，我就知道我的修改對以前的改動
是不是造成了負面的影響。
乙個月下來，我能執行的測試類有140多個，需要注意的是，我並非寫了140個測試方法，因為
有的測試類是通過繼承來實現的，這是因為有許多畫面，可能就是商品種類不同，剩下的都相同。
這樣，每次系統改動的時候，我只要把這些測試全執行一次，就知道我負責的模組是不是有問題。
那麼其他人呢？他們仍然在手動測試，每次乙個更新，他們都要手動去測試每乙個地方，而且
不能保證測試到了每乙個地方。
那麼我來計算一下成本吧！就算我那140個測試方法都是單獨的，每個方法我需要10分鐘，
那麼我需要 1400 分鐘，1400/60 = 23.3 個小時。也就是說，乙個月下來，我只需要多付出23.3個
小時。
那麼收益是多大呢？乙個月後，我只需要20分鐘就可以知道系統是不是存在錯誤，而他們卻
需要幾個小時，而且未必準確。
再來說說那個國內的專案。那個專案我要求了使用tdd的方式，因為這是乙個從零開始的項
目。在實現乙個功能之前，首先編寫測試方法，確定了這個功能要實現什麼目標，如果有錯誤，
該提示什麼樣的錯誤資訊。
根據經驗，乙個測試方法大概需要10-20分鐘，到目前為止，大概完成了25%，一共有40個測試
方法，那麼成本就是 400/60 = 6.7 個小時。收益呢？目前只要做了任何乙個改動，只要跑一遍測
試，就可以知道系統是不是存在問題。
我通過了2個實踐的例子來說明tdd的優勢，其實歸根到底，tdd從開發方面，節省了我們的
測試資源，從使用者方面，保證了產品的質量，從老闆的角度來說，其實是用小的成本換來大的收
益---為什麼這麼說？小的成本其實就是測試方法的編寫，大的收益就是產品質量的保證，以及更
好的產品，吸引來更多的客戶。
但是，就是這麼一點點的成本，或許是再稍微多一點的成本，讓很多公司望而止步。很多人仍然
認為這些成本可以省掉。因為理由很充分：你看那麼多公司，不是仍然效益很好，顧客很滿意嗎？
其實如果深入到那些公司內，就會發現：維護的專案是多麼的糟糕，每次release，如何保證這次
的改動不會造成影響？除了讓qa的人測試大量的case，還有別的辦法嗎?
「我們修改了乙個bug，但同時又創造了乙個新的bug。」這個神話不是我們自己創造的嗎？
我想tdd還有漫長的道路需要走下去，需要更多的時間來獲得人們的認同，只是目前的情況，
只能是tdd，想說愛你不容易！
如果你是乙個準備購買軟體的客戶，那麼你可以毫不猶豫地要求軟體開發商使用tdd的方式，
因為你應該知道這樣做其實是在保護你的利益。
如果你是乙個老闆，那麼你應該立刻要求下屬學習並實踐tdd，如果客戶不買單，那麼你應該
買單，因為你應該相信，微小的成本會換來更好的軟體，更好的軟體會迎來更多的客戶。
如果你是乙個開發人員，那麼你應該立刻學習並實踐tdd，如果你的客戶和老闆都不準備買
單，那麼就自己買單。你應該相信，微小的付出，會換來更多的價值！
IT 想說愛你不容易
檢查了半天，也跟蹤了伺服器端的執行日誌，沒有發現什麼問題，重啟伺服器程序，繼續跟蹤排程程序和執行程序，依舊沒有看出什麼問題，後來根據日誌中的select語句又到資料庫裡面查了一下，嘿！居然沒有資料。估計是命令解析的時候出了錯誤，看來是程式問題了，在伺服器上找到執行程序的源程式，make clean ...
ROR TDD，想說愛你不容易
tdd，也就是 test driven development 測試驅動開發，其實是一種開發方式的巨大提高。它 提出了一種新的開發方式 以測試為驅動。在此，我仍然想引用乙個曾經看過的thoughtworks的 乙個人的blog中的一句話 什麼是tdd？tdd就是把你的需求用測試給描述出來。這句話一下...
東航，想說愛你不容易
我坐東航的航班是小概率事件。自05年6月做諮詢以來，平均每月飛行12次，到現在大概有600次的飛行記錄，坐東航的航班大概有10次。在10次的記錄中，印象裡只有一次準點，因此，在我印象裡 東航準點也是小概率事件，所以,除非萬不得已，我不坐東航的航班。從今年五一到現在，今天是第三次坐東航的航班，次次晚點...