單元測試和測試驅(qū)動開發(fā)的一些常見問題總結(jié)

2019-11-17 03:10:55

字體：大中小

供稿：網(wǎng)友

單元測試和測試驅(qū)動開發(fā)的一些常見問題總結(jié)

此文收集一些平時使用單元測試碰到的問題和解決辦法，供大家參考。

如何檢查返回的集合類是否符合期望？

Microsoft UnitTestFramework	如果需要元素的順序一致，可以使用CollectionAssert.AreEqual；如果不需要考慮順序，可以使用CollectionAssert.AreEquivalent。（有的地方說MSTest的Assert.AreEqual支持集合類型比較，我測試過，忽悠人的）
nUnit	同上
xUnit	xUnit的Assert.Equal(c1, c2)可以支持集合類型比較，c1和c2的元素順序必須一致

Microsoft UnitTestFramework / nUnit / xUnit 比較，使用哪個框架更合適?

Microsoft UnitTestFramework和nUnit的用法非常類似，而xUnit由于吸取了nUnit的設(shè)計上的經(jīng)驗，用法更加簡潔。下面是周公寫的兩篇文章，nUnit和xUnit介紹的非常詳細(xì)，大家可以閱讀一下：

在.NET開發(fā)中的單元測試工具之(1)——NUnit
在.NET開發(fā)中的單元測試工具之(2)——xUnit.Net

什么是Mock？

單元測試的目標(biāo)是一次只驗證一個方法，小步的前進(jìn)，細(xì)粒度的測試，但是假如某個方法依賴于其他一些難以操控的東東，比如說網(wǎng)絡(luò)連接、數(shù)據(jù)庫連接、系統(tǒng)時間、或者是Servlet容器，那么我們該怎么辦呢？要是你的測試依賴于系統(tǒng)的其他部分，甚至是系統(tǒng)的多個其他部分呢？在這種情況下，倘若不小心，你最終可能會發(fā)現(xiàn)自己幾乎初始化了系統(tǒng)的每個組件，而這只是為了給一個測試創(chuàng)造足夠的運行環(huán)境讓它們可以運行起來。忙乎了大半天，看上去我們好像有點違背了測試的初衷了。這樣不僅僅消耗時間，還給測試過程引入了大量的耦合因素，比如說，可能有人興致沖沖地改變了一個接口或者數(shù)據(jù)庫的一張表，突然，你那卑微的單元測試的神秘的掛掉了。在這種情況發(fā)生幾次之后，即使是最有耐心的開發(fā)者也會泄氣，甚至最終放棄所有的測試，那樣的話后果就不能想像了。

再讓我們看一個更加具體的情況：在實際的面向?qū)ο筌浖O(shè)計中，我們經(jīng)常會碰到這樣的情況，我們在對現(xiàn)實對象進(jìn)行構(gòu)建之后，對象之間是通過一系列的接口來實現(xiàn)。這在面向?qū)ο笤O(shè)計里是最自然不過的事情了，但是隨著軟件測試需求的發(fā)展，這會產(chǎn)生一些小問題。舉個例子，用戶A現(xiàn)在拿到一個用戶B提供的接口，他根據(jù)這個接口實現(xiàn)了自己的需求，但是用戶A編譯自己的代碼后，想簡單模擬測試一下，怎么辦呢？這點也是很現(xiàn)實的一個問題。我們是否可以針對這個接口來簡單實現(xiàn)一個代理類，來測試模擬，期望代碼生成自己的結(jié)果呢？幸運的是，有一種測試模式可以幫助我們：mock對象。Mock對象也就是真實對象在調(diào)試期的替代品。

什么時候需要使用Mock？

關(guān)于什么時候需要Mock對象，Tim Mackinnon給我們了一些建議：

真實對象具有不可確定的行為(產(chǎn)生不可預(yù)測的結(jié)果，如股票的行情)
真實對象很難被創(chuàng)建(比如具體的web容器)
真實對象的某些行為很難觸發(fā)(比如網(wǎng)絡(luò)錯誤)
真實情況令程序的運行速度很慢
真實對象有用戶界面
測試需要詢問真實對象它是如何被調(diào)用的(比如測試可能需要驗證某個回調(diào)函數(shù)是否被調(diào)用了)
真實對象實際上并不存在(當(dāng)需要和其他開發(fā)小組，或者新的硬件系統(tǒng)打交道的時候，這是一個普遍的問題)

如何使用Mock？

.NET Mock Framework有哪些，可以看看下面幾個網(wǎng)頁：

.NET Mocking Framework對比
What C# mocking framework to use?
The Fakes Framework in Visual Studio 2012

關(guān)于Mock框架的實現(xiàn)方式，大概有兩種：基于動態(tài)代理實現(xiàn)；基于編譯時靜態(tài)織入實現(xiàn)。各個框架的用法看一下介紹很快就可以掌握了，關(guān)鍵是如何使用各種mock技術(shù)，存在的爭論主要有下面幾個：

爭論一：像Typemock、Moles、Visual Studio 2012 Fakes Framework這類靜態(tài)織入技術(shù)的框架，可以支持對Sealed Class、Non-Abstract Method、Non-Virtual Method、Static Method的Mock。有些人覺得這很強(qiáng)大，有些人覺得這反倒不好，他們認(rèn)為像Moq、Rhino Mocks這類的框架，正因為不支持前面說的四類情況的mock，強(qiáng)迫項目必須實現(xiàn)依賴倒置，從而降低了項目的耦合性，以達(dá)到較高的可測試性以及可維護(hù)性。
爭論二：在使用動態(tài)代理方式的Mock框架時候，為了“可測試性”，PRotected方法必須是virtual的，因為我們需要在子類中進(jìn)行override。同理，Mock框架能夠輔助的方法也必須是virtual的，即使是一個public方法。那么，您覺得這是為了可測試性而做出的讓步嗎？或者換句話說，您覺得，一個不可以override的protected方法，但是會影響到其他公開接口的功能，這是不是一個合理的設(shè)計呢？如果這是一個合理的設(shè)計，又不想作出這樣的讓步……我們又該怎么做呢？（這段話摘自老趙的“與protected成員有關(guān)的單元測試方式”）
爭論三：在使用動態(tài)代理方式的Mock框架時候，為了測試一些Non-Abstract Method、Non-Virtual Method、Static Method，提供一個被測方法/類的Wrapper，封裝對無法直接訪問方法的調(diào)用，是否合適？做法參考：http://blog.zhaojie.me/2009/08/unit-test-protected-method.html#comment_iX2whQ8q04I003i2http://blog.zhaojie.me/2009/08/unit-test-protected-method.html#comment_iX2whQ8q04I003hi

關(guān)于爭論一，我的考慮的結(jié)果如下：

實際情況中，我會根據(jù)項目實際情況來選型。考慮的因素主要有：

是否需要支持私有方法、Non-virtual方法的單元測試：實際情況中，項目的代碼結(jié)構(gòu)不一定是想象中的理想情況，這個時候就需要考慮Typemock、Visual Studio 2012 Fakes這類框架。
開發(fā)效率：能夠花最小的成本完成單元測試工作，獲得最大的收益。使用復(fù)雜，開發(fā)效率低的框架的優(yōu)先級自然要排在后面。
集成難易程度：一般單元測試用例會在提交代碼的時候跑一遍，作為保證提交代碼質(zhì)量的一道關(guān)卡。單元測試框架是否能和現(xiàn)有持續(xù)集成工具很好的集成在一塊，也是要考慮的因素。
運行效率：跑的越快的框架，能夠減少每次驗證的時間成本。

什么是“測試驅(qū)動數(shù)據(jù)庫開發(fā)”？

測試驅(qū)動數(shù)據(jù)庫開發(fā)，也稱為TDDD（Test-Driven Database Development），是把TDD的理念運用到數(shù)據(jù)庫開發(fā)的過程中，通過數(shù)據(jù)庫測試來定義數(shù)據(jù)庫的行為，如同通過測試定義應(yīng)用程序代碼邏輯一樣，來保證數(shù)據(jù)庫重構(gòu)過程中的質(zhì)量。

使用 TDDD 的優(yōu)點包括：