iT邦幫忙

DAY 23
6

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

[如何提升系統品質-Day23]測試 - 單元測試工具的選擇(for .NET)

前面的文章,介紹了單元測試的意義,以及單元測試的範例

業界很多朋友知道我有在做單元測試,常問我:要選NUnit好?還是用Visual Studio內建的單元測試好?

這邊針對我的一些使用經驗,簡單的介紹一下測試相關工具的差異。

[如何提升系統品質]系列文章連結
NUnit好,還是VS內建的單元測試工具好?
我之前的單元測試撰寫經驗,都是使用NUnit,原因很簡單:免費。 免費的重點在於,其他的工具對它的整合程度會比較高。

這邊所謂的其他工具,最重要的就是CI server。
有很多的CI server也都是免費的,對這些open source的工具來說,NUnit是一個輕巧簡便,該有的都有的單元測試工具。

但,假設不管單元測試以外的相容性部分,我得說VS內建的單元測試大勝!

單元測試導入難在哪?難在很多步,第一步最難的就是dev的心理障礙。
dev的心聲:
1.測試程式?為什麼我寫code都沒時間了,還要我寫測試程式?
2.針對一個功能寫一份production code就夠吃緊了,還要寫好幾份測試程式來測這一份code?
3.程式碼一改,需求一改,原本只要改一份production code,現在要改1+N份程式?
4.測試程式有寫跟沒寫一樣,為什麼我還要新增一個專案,手刻一個測試的class,測試的方法,還要寫相關的輸入、驗證相關的輸出?每次都刻這個真的很浪費時間。

是的,單元測試導入最難的第一步,就是工程師覺得寫測試程式不夠方便、快速,是額外的負擔。

Visual Studio的單元測試可以為我們做到什麼
1.自動產生測試程式相關框架
在Visual Studio裡面,建立測試專案、建立測試類別、建立測試方法、建立測試目標初始化、測試方法參數初始化、驗證的語法,都是自動產生的。其中還包括了,該測試類別每次初始化與結束要進行的方法,測試方法執行前後要進行的方法,也都自動產生好了。

NUnit也有相關自動產生測試程式的工具,例如NUnit Test Generator,也是要錢。或是免費,但沒持續升級的工具:NUnit Test Case Code Generator

2.提供Data-Driven Test
在VS的單元測試中,可以透過精靈去設定該方法需要哪些測試案例,在同一個方法中,測試每一個input, output是否符合原本的預期。

3.與開發工具IDE的整合
例如執行測試的熱鍵,雖然說這不是每個人都需要,而且也可以自己設定,但在開發過程中,Unit Test的程式碼跟Production code其實是一體兩面的。都要可以建置成功,都要可以被測試成功。寫出的每一個功能都應該要能符合預期。

在code coverage的整合上,VS內建的程式碼涵蓋率,還是比R#(要錢)跟NCover(要錢)的整合好多了。Code Coverage的工具一樣都要錢,VS的工具則可以跟開發的程式順利的整合在一起。

偵錯上,也可以把測試程式就當作production code一樣來偵錯,相當方便。
NUnit則需額外透過其他套件來執行,例如TestDriven.NET(要錢)與Visual Nunit

簡單的說,你需要用到的,基本上VS內建的都有。而NUnit就像一個內聚力很高且功能良好的單一單純的單元測試工具,需要更多其他的工具輔助,才能擁有多面向的綜效。

4.Class Accessor的產生
個人認為,這一點跟自動產生的效益是最高的。VS內建的單元測試,打破了一般單元測試的基本原理,也就是只能測試類別公開出來的部分。在VS的單元測試裡,只需要滑鼠右鍵,產生單元測試,連所有的private, protected, internal, public都可以測試。這時候VS會幫你產生一個Accessor的class(類似proxy的概念),並將其所有屬性、方法、事件等非公開的部分,public出來協助進行測試。

如果沒有這樣的方式,原本的測試方式只能:
(1)在設計production code時,為了測試方便,將其public給外界。但這樣帶來的後果,我個人認為得不償失。無論如何,都不該因為『for 測試方便』而修改production code,且導致production code在visibility上品質是下降的。
(2)透過其他public的方法,來黑箱測試非public的部分。也就是外部只care類別public的部分,因為外部也只能用public的部分。這雖合理,但單元測試想要測試的方法,若是黑箱測試,則失去最大效益。

5.不只Library可以測試
Web Application, Website, Console(SilverLight, WCF服務網站跟Winform我沒試過),也都可以直接透過一樣的方式,產生測試專案、測試方法。

這真是一大福音,如果為了要做測試,而進行大幅架構型的重構,才能進行測試。那再重構之前就需冒著production code被改壞的風險。但不重構,又無法讓程式具備可測試性。這時候透過VS內建的測試工具,可以幫我們產生對應的測試(其實應該歸類在整合測試),讓整個重構的cycle可以啟動,這也是NUnit不容易辦到的。

結論
NUnit與VS內建Test之爭,簡單的說就是open source工具的組裝,以及Total Solution的比較。

如果,你們已經使用相當多的open source工具,來做軟體工程與開發工法程序相關的infrastructure,且針對的對象,不只是.NET。那,我會建議使用NUnit。

如果,你們是使用TFS來做版本控管以及CI Server,那千萬不要捨棄VS內建的單元測試,這會讓你事半功好幾倍,如有神助一般。

如果,你們還在考量要使用哪一種,沒有其他包袱,又希望導入快速、成功,那我會建議使用TFS+Visual Studio。Total solution的問題點只有:
1.錢。
2.工具相依於MS。

而工具相依特點的另外一面卻也是優點,代表即使Visual Studio版本的migration, .net framework的migration, CI的migration,微軟都會以他們所支援的工具、技術為主要優先support。

Open source的缺點:
1.需要大量的survey與組合多個工具。且這裡的組合,基本上都脫不了寫code。如果不必寫code,恭喜你,肯定又有open source的IDE工具幫你做掉,如果好用,它肯定要收費。

2.當組合多個工具,一切盡善盡美時,相信微軟又將IDE開發工具、.net framework等等,往上提升了一個版本,這時候多個工具組合出來盡善盡美的聖戰士,就可能會面臨升級升不上去的窘境。

3.當你大刀闊斧的撩下去改open source的工具,以客製化因應你們系統上的需求時,open source的migration又補你一刀。屆時就會面臨:migration open source tool,可以支援較新的MS技術版本,但又得重新客製化一次。不migration,又無法以新的技術來開發新的系統。

Open Source大部分都是一些神人的休閒之作,他們懷著一顆懸壺濟世的心情來對這個世界貢獻,他們創造了許多的美好,推動了許多技術的演進,但他們也有家庭要顧,也有小孩爹娘老婆要養。所以很難在短時間內,馬上就跟上微軟技術的演進。而CI, Unit Test, 這種跟開發息息相關的infrastructure,卻很難因為open source的作者沒空migration而作罷。

這就是我建議的,如果錢夠,又沒包袱,Total Solution增加的購買成本,會相對的降低未來升級成本。且開發上的簡便、迅速,可以買到工程師的快樂,導入軟體工程的成功率也比較高,就看管理者的目光看多遠了。

其他的Reference
1.NUnit vs. MsTest: NUnit wins for Unit Testing.
2.NUNIT和VISUAL STIDIO的比較
3.MSTest vs. NUnit with Visual Studio 2010 & TDD


上一篇
[如何提升系統品質-Day22]測試 - 單元測試的意義
下一篇
[如何提升系統品質-Day24]測試 - Code Coverage
系列文
如何提升系統設計品質 - 技術與工具以.NET為例30

尚未有邦友留言

立即登入留言