** 本文同步發表於 軟體設計鮮思維FB社群 **
看到國外某作者的一篇論述:「Lean Testing or Why Unit Tests are Worse than You Think」。這篇文章我瀏覽了兩遍,思考原作者從什麼樣的角度來看待所謂的單元測試 (unit test)。
文內有提,他純粹從經濟 (economic)的觀點來看待測試,然後接著從三項因子:成本 (Cost)、速度 (Speed)、信心 (Confidence)來比較 整合測試 (integration test) 與 單元測試 (unit test)的價值。
他的結論是認為:整合測試相對來得有價值許多。🤔
然後接著他再用 投資報酬率 (ROI, Return on Investment)與 程式覆蓋率 (Code Coverage)來佐證 整合測試 的高投資率。
這就讓我更肯定了,原作者是站在專案經理人 (PM, Project Management)的角度來看待整合測試,PM 最是偏好用指標來衡量投報率與顯性價值等。
問題是,投報率、覆蓋率等這些指標,是極難衡量隱性的因子與其所創造的價值啊! 試想想,該如何衡量軟體產品的彈性度、擴展性與維護性議題呢?
再則,整合測試與單元測試根本是兩種不同的構面與不同角色的人所負責的:
o 整合測試:產品釋出 (release)前涵蓋所有元件的測試,一般由 QA 品管專職人員擔任。
o 單元測試:系統開發期間對必要 (essential)性類別 (如 控制物件、資料存取物件、企業物件等)的測試,這必然由撰寫該類別的開發人員負責撰寫,不得假手他人。
另文內雖提及了 TDD (他可能以為單元測試就代表 TDD),但我蠻確定原作者並不真正了解所謂 TDD (Test Driven Development),測試驅動開發的涵義。
TDD 會規劃該類別應有的測試案例,並依此來撰寫測試程式。藉由測試案例與測試數據逐漸越完整的情況下,來引導實現該類別功能的完整與正性性。 (如此說來,這反而對單一類別的程式覆蓋率更高才是!)
還有更為重要的是,TDD 講究程式碼一開始並不會完美,冗長多餘、不易解讀的程式碼,一開始是為了滿足功能的正確性,而後才藉由測試程式的把關,逐漸施以重構 (refactoring)的手段,讓程式碼越形分散、責任更專一、更容易解讀好維護。
最後,還是強調:整合測試是絕對必要的,這是整體產品釋出前的最後一道關卡。
而單元測試,記得,這是開發人員自身對所謂精要 (essential)性的類別來撰寫單元測試,這是對自己負責任的態度。
有單元測試對單一類別的把關,反之整合測試更能順暢整合,當發現錯誤時,也相對容易抓出問題的瓶頸落在哪一個環節上。兩者是互補,且是由不同角色、不同期間的產物,不太應該拿來二分法的。
> TDD 講究程式碼一開始並不會完美,冗長多餘、不易解讀的程式碼,一開始是為了滿足功能的正確性,而後才藉由測試程式的把關,逐漸施以重構 (refactoring)的手段,讓程式碼越形分散、責任更專一、更容易解讀好維護。
現在常遇到的情形是上一批的需求完成後,緊接著就要做下一批的需求 …
所以如果想重構,只能自己找機會偷做了 …
如果重構不是減輕你的寫碼工作反而增加工作量,那就沒有重構的需要了。 🙂
反之重構如可以提升你的生產力以及降低維護性,那當然就要重構囉~。
這一切都端賴 PG 乃至團隊乃至公司是如何看待重構的。