不平凡軟件,始于2014
鄭州軟件開發告訴你一些測試驅動開發的經驗
無論你是做哪個行業的,只要與計算機相關,你就應該聽過或讀過不少關于測試驅動開發的討論,測試驅動開發往往被比喻為神奇的獨角獸,它能幫你照看你的軟件,讓大家樂得其所。于是,在寫了18.000行“神奇獨角獸”代碼后,我想把我們的體驗從整體的角度闡述一下。鄭州軟件開發!
真相其實是,測試驅動開發真TMD太痛苦了。寫那些沒完沒了的測試需要很強的自律,遠不是你想象的那么簡單容易。
但你知道什么更讓人討厭嗎?是缺少這些測試而出現的麻煩。
讓我澄清一下。我并不是想來勸說你去實施測試驅動開發。我想做的只是要給你一個真實的認識,讓你明白TDD是如何工作的,以及你能從中得到哪些好處。
對軟件開發來說,我基本上把測試驅動開發當做一種保險。它能保證你的軟件有一個預設的質量關卡,大多數是依據bug的數量和軟件變更的風險度來判定。它同時能降低萬一你的主要開發人員被車撞后造成的損失,以及你的軟件所依賴的平臺上的API遭遇類似事件所帶來的危害。
然而,在我們所生活的這個星球上,仍然有成百萬的人每天過著沒有保險的生活,很顯然,達到目的的方式并不是只有一條途徑。這完全依賴于你的責任心和你能或你想怎么去做事情。
在Transloadit公司,我們 100%的代碼都是由測試驅動開發的。我們這樣做的主要原因是我們的系統用了node.js,這種技術目前來看在某種程度上仍然是有很高的風險的技術,也許這正是我們最大的麻煩,但同時也是我們最大的優勢所在。另外一個很大的風險是我們使用的第三方工具包,例如ffmpeg和image magick,這些東西在升級時出奇的危險,因為它們動不動就改變API和接口運行方式。而最后一個,但絕對不是最不重要的一個,是我們的某些東西太復雜了。
現在,讓我解釋一下我們如何利用測試驅動開發來避免這些風險的。首先,在開發所有的新功能前先寫系統測試。所有的系統測試都是利用整套的REST service,它產生真實的HTTP請求,評估響應的信息,同時也檢查這個過程中產生的文件。我們通過文件的元數據信息來確認文件,對于圖片我們使用特定的設計進行可視化比較。對于視頻我們使用截屏圖像進行可視化對比。
一旦寫出來測試程序(也許是失敗的測試),我們就開始寫單元測試。讓我來解釋一下我們所說的“單元“。對于我們來說,一個單元是我們能測試的一個最小粒度的功能片段。只要存在函數調用,類的創建,甚至閉包的回調,我們都會把它挑出來。所有的測試都是孤立的、分離的、能夠自動的運行處理。你可以想象的出,這部分工作是痛苦的,需要勇氣。
可是,產生的結果卻是不可否認的漂亮。寫這些測試感覺就像是在驗證數學理論。每一個步驟都是能夠分解的最小的邏輯單元。所有的步驟都是基于之前的一步。沒有必要每次都測試所有的 1 – 1000000個功能點,除非你有邏輯上的需求,需要一個特殊結果。
很顯然,在這個過程中你有很多機會去做傻事,或者迷失了原始方向。這時系統測試就來拯救你了。任何當你不知道下一步該做什么的時候,只要運行一下系統測試,它就會告訴你還少些什么要做。
完美的過程嗎?不,在我們的產品中的這里或那里,多少都會有些bug,但不多,我十個手指頭都能數過來。上周末,我們對我們的產品做了一個瘋狂的改動:我們把底層的MySQL驅動(我們用的是PHP,別問我怎么做的)換成了node-mysql。我們已經在node-mysql上工作了,同樣使用的是TDD-masochism,升級相當的平穩(目前為止)。這種成績對于一個牽涉有6000行代碼的改動來說很不錯了。
這就是我們做的。并不會由于我們使用了TDD,我們公司的產品就必然的優于我們的競爭對手。但我們承擔的風險要小的多,我們可以輕而易舉的做心臟手術。這給了我們分配資金的信心,給了我們能力去把剩余有限的資源(我們做事情步步為營)使用在新功能的開發上,而不是花在解決我們軟件里無處不在的缺陷上。
那么,TDD適合你嗎?這要視情況而定。按TDD模式寫程序需要很強的自律,獨角獸不會一直陪在你身旁讓你放心。想好了再去這樣做。有時一些系統測試程序會用掉你80%的努力來測試只是20%的工作。而有些情況會讓你把剩余的20%也搭上。我們很幸運能使用一種靈活的語言,我們大部分的接口都是使用的JSON。這使我們的測試成本更低。這些我們銘記在心。
不平凡軟件,鄭州軟件開發公司,鄭州軟件開發,鄭州軟件定制,鄭州微信開發,鄭州進銷存定制開發,鄭州OA系統開發,鄭州軟件開發公司
相關新聞換一組