microsoft unittestframework
如果需要元素的順序一致，可以使用collectionassert.areequal；如果不需要考慮順序，可以使用collectionassert.areequivalent。（有的地方說mstest的assert.areequal支援集合型別比較，我測試過，忽悠人的）
nunit
同上 xunit
xunit的assert.equal(c1, c2)可以支援集合型別比較，c1和c2的元素順序必須一致
microsoft unittestframework和nunit的用法非常類似，而xunit由於吸取了nunit的設計上的經驗，用法更加簡潔。下面是周公寫的兩篇文章，nunit和xunit介紹的非常詳細，大家可以閱讀一下：
單元測試的目標是一次只驗證乙個方法，小步的前進，細粒度的測試，但是假如某個方法依賴於其他一些難以操控的東東，比如說網路連線、資料庫連線、系統時間、或者是servlet容器，那麼我們該怎麼辦呢？要是你的測試依賴於系統的其他部分，甚至是系統的多個其他部分呢？在這種情況下，倘若不小心，你最終可能會發現自己幾乎初始化了系統的每個元件，而這只是為了給乙個測試創造足夠的執行環境讓它們可以執行起來。忙乎了大半天，看上去我們好像有點違背了測試的初衷了。這樣不僅僅消耗時間，還給測試過程引入了大量的耦合因素，比如說，可能有人興致衝衝地改變了乙個介面或者資料庫的一張表，突然，你那卑微的單元測試的神秘的掛掉了。在這種情況發生幾次之後，即使是最有耐心的開發者也會洩氣，甚至最終放棄所有的測試，那樣的話後果就不能想像了。
再讓我們看乙個更加具體的情況：在實際的物件導向軟體設計中，我們經常會碰到這樣的情況，我們在對現實物件進行構建之後，物件之間是通過一系列的介面來實現。這在物件導向設計裡是最自然不過的事情了，但是隨著軟體測試需求的發展，這會產生一些小問題。舉個例子，使用者a現在拿到乙個使用者b提供的介面，他根據這個介面實現了自己的需求，但是使用者a編譯自己的**後，想簡單模擬測試一下，怎麼辦呢？這點也是很現實的乙個問題。我們是否可以針對這個介面來簡單實現乙個**類，來測試模擬，期望**生成自己的結果呢？幸運的是，有一種測試模式可以幫助我們：mock物件。mock物件也就是真實物件在除錯期的替代品。
關於什麼時候需要mock物件，tim mackinnon給我們了一些建議：
.net mock framework有哪些，可以看看下面幾個網頁：
關於mock框架的實現方式，大概有兩種：基於動態**實現；基於編譯時靜態織入實現。各個框架的用法看一下介紹很快就可以掌握了，關鍵是如何使用各種mock技術，存在的爭論主要有下面幾個：
實際情況中，我會根據專案實際情況來選型。考慮的因素主要有：
測試驅動資料庫開發，也稱為tddd（test-driven database development），是把tdd的理念運用到資料庫開發的過程中，通過資料庫測試來定義資料庫的行為，如同通過測試定義應用程式**邏輯一樣，來保證資料庫重構過程中的質量。
使用 tddd 的優點包括：
單元測試的一些總結
productmodeldaoimpltest 測試類，productmodeldaoimpl 被測試類。1 實現 unitilsjunit4 public class productmodeldaoimpltest extends unitilsjunit4 2 聲名被測類得屬性 testedob...
測試驅動開發 JUNIT 單元測試類
單元測試需要構造資料 而且會考慮到事務的回滾等等問題,測試 的構建如下 路徑問題 1 在 src 目錄下 runwith org.springframework.test.context.junit4.springjunit4classrunner.class contextconfiguratio...
測試驅動開發之基礎 單元測試
學習測試驅動開發之前，應當正確理解一下單元測試的概念，學習單元測試之後可以清楚的知道所謂的單元為單一職責的乙個方法即乙個方法只做一件事情，這也符合物件導向的單一職責的原則。因此單元測試的概念可以籠統的理解為 針對乙個工作單元設計的測試。單元測試有各種不同的編寫方式，但所有單元測試有些共同的特徵 1....