TDD,想說愛你不容易

2021-08-29 09:11:02 字數 2625 閱讀 2439

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次的記錄中,印象裡只有一次準點,因此,在我印象裡 東航準點也是小概率事件,所以,除非萬不得已,我不坐東航的航班。從今年五一到現在,今天是第三次坐東航的航班,次次晚點...