談到測試,許多開發者的心總是糾結的,寫測試需要時間,有時花的時間比寫被測的程式還多,寫測試有難度,特別是被測對象沒有提供適當的工具或掛勾可供測試之時。寫測試也需要思考,有時根本不知道應該測什麼東西,或不該測什麼,最後淪為遵守教條,為了測試而測試。

從測試自動化開始

談到測試與教條,開發者多半會想到的就是測試驅動開發(Test-Driven Development, TDD),在《測試驅動開發-使用Python》第一章開頭,就強調出測試驅動的第一紀律:「服從測試羊!除非你有測試程式,否則別做任何事情」,如果從沒試過測試驅動,可以試著跟上書中的每個操作,到後期程式變得複雜時,就會感謝有測試的存在。

測試驅動的嚴格紀律,也帶來了不同評價,最有名的一次戰爭,莫過於Uncle Bob、Kent Beck等大師,摃上Rails創建者David Heinemeier Hansson所發表的〈TDD is dead. Long live testing.〉(https://goo.gl/ci3xzO)。無論如何,這表明了,想要遵守測試驅動的嚴格紀律,需要有一段正確學習、訓練與習慣的過程,嚴格遵守紀律是有價值的,特別是涉及到軟體開發,而不單純是程式設計之時,畢竟〈程式設計不等同於軟體開發〉(https://goo.gl/qNMxHO)。

回歸到自然一點的角度來看,有時我們只是想單純享受一下程式設計的樂趣,從一個隨意撰寫的原型開始,逐步驗證想法再演進程式,會想要先撰寫測試程式嗎?可能不會,然而,這不表示程式不需要測試,也不代表程式的撰寫過程中,不會進行任何測試。實際上,幾乎不會有一名開發者寫完程式不動手測試的,就算是個Hello, World之類的,也會看看有沒有正常顯示、跳出視窗之類的吧!

手動地測試每個人都有過,也就是說,就算不採測試驅動,程式仍是需要測試的,然而,就算是從隨意的原型開始演化出來的一人專案,也可能會開始日趨複雜,手動測試變得重複、繁瑣,因而引發出耗費時間、容易遺落測試案例等問題。因此,如果發現到某個頁面需要按十幾次確定按鈕來關掉警訊方塊,還有什麼理由去拒絕自動化這個過程呢?

我該怎麼測?

有的!很多人會拒絕測試的理由之一是,不知道有什麼工具可以使用,然而,這不是正當的理由,就現今主流平臺、語言,或者一些受歡迎的程式庫、框架來說,多半都能找到可用的測試工具,像是《測試驅動開發-使用Python》中,就談到了unittest、Selenium等,而Django本身也提供了一些測試掛勾(hook)用的API,只要略為調查,在工具方面想要有個起點,應不是難事。

很多人會拒絕測試的理由之二是,不知道怎麼針對目標程式寫測試,實際上,如果不知道該怎麼寫測試的時候,才更要寫測試,這給了程式碼一個重構的好機會與目標——在正式寫測試之前,先試著整理程式碼,重構的過程中,得不斷地問自己,對於看似無法測試的模組來說,之前手動時到底是想測出什麼?逐步地將想測試的程式碼集中,甚至抽取出子函式或模組,程式碼的意圖就會被突顯出來,程式意圖一旦清楚明瞭,就會知道該測試什麼、不該測試什麼,以及該如何測試。

舉例來說,3D建模時該怎麼測試模組?模組是一個有副作用的輸出,OpenSCAD本身並沒有測試用的掛勾,而針對匯出的模型檔案(像是STL)是不切實際的,因為動輒數十MB且難以事先準備測試材料(fixture),在試著為模組加入測試的過程中,我總是先重構,對於抽取出來的子函式或模組發問:「這是我想測試的對象嗎?我該對它測些什麼」。

子函式往往是沒問題的,OpenSCAD的函式必須是純函數式,因此沒有副作用,一個輸入只會有一種輸出,非常適合測試,這樣我就在一個原本看來無法測試的模組,找出可測試的部份了,往往地,發掘出來的子函式越多,可測試的比例就越高,最終不可測試的部份,就會被擠壓到某個邊界。

如果不可測試的部份已推到須呼叫內建模組的地步,可能就不需要測試。搞清楚測試的邊界很重要,不需要測試你所採用的程式庫或框架之功能,只需要測試傳給內建模組前的引數是否符合預期。例如,在OpenSCAD,不用測試內建的polyhedron是否正確繪出多面體,而是要查看那些演算出來預計傳給polyhedron的座標點,是否符合預期。

因此,對於一些顯而易見的模組,也是不需要測試的,例如底下這個hexagon模組,因為circle是內建模組,轉動30與邊數為6都是固定的,簡單來說,這不過就是個膠合用的模組,不需為了測試而測試:

module hexagon(r_hexagon) {
rotate(30) circle(r_hexagon, $fn = 6);
}

認清測試之目的

往往地,認清「不」該測試什麼,跟知道該測試什麼同等的重要,這可以避免為了測試而測試。在〈The tragedy of 100% code coverage〉(https://goo.gl/YaBTsF)中,也看到類似的說法,作者談到在辦公室曾對某個開發者說過,某個方法不需要寫測試,因為「程式碼顯而易見,沒有條件判斷、沒有迴圈、沒有轉換,什麼都沒有,這程式碼不過是簡單的老膠合程式碼。」

將一個無法測試的程式碼進行重構,從而使之能夠進行測試,實際上也是測試的目的之一,也就是「讓程式碼變得可測」,這除了能提高自動化測試的比例之外,過程中也會發現一些事先沒考量到的問題,未來在修改程式碼時,也才能保證程式結果沒有被破壞,一切仍如當初預期之方式運行。

這也說明了另一件事,測試並不是保證撰寫出來的程式碼是正確、沒有臭蟲的,只是證明程式碼符合預期,有句老話說:「程式是照你寫的跑,不是照你想的跑」,測試可以說只是用來確定「程式也是照你想的跑」,然而,想的卻不一定是正確、無臭蟲。

換個角度來看,如果已經有段可運作且符合預期的程式碼,然而還沒加上測試,可試著為它加上測試,未來若程式之需求有了變動,也才能確保相關程式碼之行為,甚至是測試程式本身,都有考慮在修改的清單之內。

如同一般的程式碼,測試程式碼也需要維護,未來若預期的行為修改,測試程式碼也要跟著修改,有時在修改測試程式碼時,為了要思考預期行為是否被確切地描述,花費的時間甚至可能更多。

花費的時間換來的是未來的防線,在《測試驅動開發-使用Python》中後期的案例中,就有不少需求變更,因為有測試作為後盾,使得一些沒被考慮到要一起修改的部份,因為測試失敗,而被提醒得去修改功能程式碼,或者是測試程式碼本身。

建立測試的掛勾

無論是測試驅動開發,或者是後來才加上測試,將不可測的程式變得可測,實際上,都有個重要的目的,為程式建立測試的掛勾,為未來留下測試的可能性。

如果是在開發程式庫或框架,提供測試的掛勾尤其重要,例如Django在這點做得很好,像是提供了LiveServerTestCase,可自動清理上次測試遺留下來的項目,就增加了開發者撰寫測試的意願。

如果使用的程式庫或框架,沒有提供適當的測試掛勾,試著從加入測試、不斷地整理、重構、思考該測些什麼的過程中,建立起自己的測試掛勾,甚至是專屬的測試框架,不但可以使得程式更為可靠,對於未來在演化、添增新功能時,就更能在一開始,將撰寫出可測試的程式作為優先考量,也許到那時,測試這件事本身也會變得自然,甚至能從中享受擁有測試的樂趣。

作者簡介


Advertisement

更多 iThome相關內容