iT邦幫忙

DAY 22
9

如何提升系統設計品質 - 技術與工具以.NET為例系列 第 22

[如何提升系統品質-Day22]測試 - 單元測試的意義

相信大家多多少少都有撰寫過Unit Test的程式,當然在軟體開發的過程中,可能因為時程或其他外在因素而導致無法持之以恆。

但套句Ruddy老師的話,『要相信雲端的程式,還是Local端的程式?都不是,應該要相信測試過的程式』。

一個程式怎麼樣才算完成可以交付,怎麼證明這個程式沒有問題,應該就要有一份測試程式來證明,這些程式在這些test case裡面,程式是沒有問題的。

在Martin Fowler的Refactoring Improving the Design of Existing Code 第一章裡提到,The First Step in Refactoring:

Whenever I do refactoring, the first step is always the same. I need to build a solid set of tests for that section of code. The tests are essential because even though I follow refactorings structured to avoid most of the opportunities for introducing bugs, I'm still human and still make mistakes.

重構是維持系統可維護性幾近於無可避免的動作,想要讓系統更乾淨、更有效率、更好維護,第一件事仍然是撰寫好測試程式,因為原本程式是可以正常運作,為了效率更好、更容易維護而導致程式結果錯誤,這是不被允許的。

撰寫可自動化的測試程式,是一個貫穿整個軟體開發過程的活動,從還沒開始撰寫實際程式,到未來維護、改版時都仍須倚重於這些測試程式。

其實在前面重構系列的文章中,有一篇就提到了Stub的用法與原由,請參考:[如何提升系統品質-Day7]測試-單元測試, Just Do It!!,這一篇則是由單元測試為切入點,來說明單元測試的一些重要資訊。

[如何提升系統品質]系列文章連結
單元測試的意義
單元測試的意義,是希望每一個測試的method,都有相當簡單明確的意義,就是要證明某一項功能在某一個case底下,程式是如預期一般運作的。

為什麼我們需要單元測試
因為整合測試有這幾個缺點,
1.整合測試無法快速的定位出錯誤點。
整合測試為黑箱測試,當測試失敗時,只知道其中的功能有錯,而無法快速準確的定位是哪一個『單位』錯了。就像下圖一樣,中間有好多的路徑都可能會出錯。

2.整合測試花費的時間太久,需要的測試環境太複雜。
正因為整合測試要跑得功能太多,環境也可能太複雜(需要外界的檔案、DataBase、服務等等...),所以需要花很多時間。對工程師來說,即使寫好測試程式,按一下測試要等2~5分鐘,是讓人相當氣餒的。倒 久而久之,越跑越久,久到乾脆不跑了。

3.整合測試涵蓋率不足。
即使我們使用了測試涵蓋率的工具,知道了哪些程式被整合測試測過,哪些沒被測過。我們卻不容易從整合測試的切入點,來補足沒有被涵蓋到的點。(雷公在雲上,要打到特定的人也是很有可能打歪的...)

以上的問題,都可以透過單元測試來解決。(前提是單元測試要寫對)

[註]基本上一個單元測試的執行時間如果超過0.1秒,就是一個很緩慢的單元測試程式。

何謂整合測試
簡單的說,就是與外部服務有相依的測試,我們稱之為整合測試。
何謂外部服務,例如以下幾種:
1.需連到資料庫。
2.需使用到網路。
3.需進行檔案存取(IO)。
4.需對測試環境進行特別的動作(例如需要先編輯設定檔,才能執行測試)。

單元測試應具備的特性
簡單用一個縮寫來表示:FIRST (參考自代碼整潔之道
Fast:快速。
Independent:獨立。
Repeatable:可重複。
Self-Validating:可反應驗證結果。單元測試不論成功或失敗,都應該要從測試的reporting直接瞭解其意義或失敗原因。
Timely:及時。單元測試應該恰好在使其通過的production code之前撰寫。

如何寫單元測試,而非整合測試
斬斷與外界服務的直接相依性,怎麼斬斷?透過介面是一個最好的方式。所有與外界服務(包括類別),都應該相依於介面,而不是直接相依於物件。(也就是IoC的方式,IoC的範例可以參考:[如何提升系統品質-Day6]重構-簡單使用interface之『你也會IoC』

這邊舉一個發票資料更新的例子 (圖片來源:Working Effectively with Legacy Code):

1.直接相依於DB class。

2.透過介面後,讓InvoiceUpdateResponder Class相依於IDBConnection,在production code中,再將DBConnection Class注入。

如此一來,在測試InvoiceUpdateResponder裡面的update()方法時,就不會與實際的DataBase相依。我們不再需要連接DataBase才能得到資料,而可以透過Stub Object的方式,直接定義該IDBConnection.getInvoices()回傳的資料清單。

何謂Stub
Stub指的是一種run time時建立的拋棄式instance,可以定義該Stub是繼承/實作哪一個介面或抽象類別,並指定哪一個方法該回傳什麼值(透過overrides方法),進而使得單元測試中的測試目標,不需與外界服務相依,而只需相依於介面,並將Stub Object注入。

實際的範例,請參考:[如何提升系統品質-Day7]測試-單元測試, Just Do It!!,裡面的步驟五,即透過Rhino.Mocks產生Stub:
1.定義這個stub物件是繼承/實作哪一個class(需要是abstract class或interface)
2.定義被呼叫哪一個方法
3.傳入哪一個參數
4.預計會回傳什麼值。

結論
透過整篇文章,您應該可以確定一下,自己寫的測試程式,是屬於整合測試,或是單元測試。

強烈建議,整合測試專案與單元測試專案要拆開來放,當在開發階段或在CI server上建立Auto Build的時候,每一次程式碼的改變(開發告一段落或簽入至版本庫),都需要執行一次完整的單元測試,才能確保這一次的版本是如同預期,且沒有影響到其他程式。

如果整合測試專案與單元測試專案綁在一起,那這個動作就會有上述整合測試的缺點:慢!

慢,就代表不好用。不好用就代表大家不想用。大家不想用就代表導入障礙提高。最後花的建置成本可能就會付諸流水。

如果您還沒開始使用單元測試,建議您跨出第一步,會感受到新奇、興奮以及相當的挫折感。挫折感的來源,來自於production code耦合性過高,可測試性低,代表品質不好。

程式不能測試=品質不好?
這麼說雖沒有錯,但不夠完整。

程式的可測試性高,代表程式的耦合度低,耦合度低,則代表程式品質『可能』有一定水準。但,程式的可測試性低,沒法子測試,或難以測試,難以『維護』測試,則代表程式耦合度高,或是程式內聚力低,則代表程式品質不佳。這是全然無誤的。

所以,程式的可測試性,是系統的重要品質指標之一。


上一篇
[如何提升系統品質-Day21]Security - Cross-Site Scripting(XSS)
下一篇
[如何提升系統品質-Day23]測試 - 單元測試工具的選擇(for .NET)
系列文
如何提升系統設計品質 - 技術與工具以.NET為例30

尚未有邦友留言

立即登入留言