1、Team Test 是 Visual Studio Test System 集成的單元測試框架，它支持：
測試方法存根 (stub) 的代碼生成。
在 IDE 中運行測試。
合並從數據庫中加載的測試數據。
測試運行完成後，進行代碼覆蓋分析。
2、測試存根的生成：
單元測試是對某個方法的測試，因此測試的單位是方法；
右鍵點擊類或者方法，“創建單元測試”；
自動生成單元測試存根時，可以選擇為一個類下的多個方法同時生成單元測試代碼。
VSTT支持對私有方法的測試，這時你可能會看到一些利用反射機制生成的代理類。（與NUnit不同）。
3、測試項目的結構組織：
首先需要將測試代碼組織到單獨的測試項目中，保持產品代碼的干淨。(VS支持專門的測試類項目)；
生成的測試項目包含了對 Microsoft.VisualStudio.QualityTools.UnitTestFramework和 待測試項目的引用。
建議每個目標類對應一個測試類，物理上對應一個.cs文件；
4、
測試代碼實現：
測試類的結構：
每個待測試目標類生成一個對應的加上 [TestClass()]聲明的測試類；
關於目標類的每個方法，對應測試類中的一個用 [TestMethod()]聲明的方法；測試方法的簽名必須是無參數的實例方法
[ClassInitialize()]和[ClassCleanup()]標識的靜態方法，表示測試類的初始化代碼和測試類中所有單元測試執行完畢後執行的方法；
[TestInitialize()]和[TestCleanup()]標識的實例方法，表示每個單元測試執行前都要運行的一段代碼；
Team Test 使用反射機制在測試程序集中搜索所有由 TestClassAttribute 修飾的類，然後查找由 TestMethodAttribute 修飾的方法來決定執行的內容
測試斷言類Assert
Assert斷言類是用來判斷測試是否通過的關鍵類，它裡面有各種各樣強大的測試方法，如果這些方法沒有獲得預期的結果，那麼測試失敗。
一個測試中可以有多個測試斷言。
Assert斷言中的出錯提示應盡可能的准確和明白。
使用 Assert.Inconclusive("TODO: 實現用來驗證目標的代碼")來表示一些尚未完全實現的測試，此時測試結果表現為一個不同於“通過”和“未通過”的第三種狀態。
期待異常：
一般方法：
[ExpectedException(typeof(ArgumentException),
"A userId of null was inappropriately allowed.")]
更靈活的方法：
在測試方法中try和catch，然後比較catch到得異常的類型和你預期的異常的類型是否相同使用，不同則報錯：
Assert.IsNotNull(exception,
"The expected exception was not thrown.");
Assert.AreEqual<Type>(
typeof(ArgumentException), exception.GetType(),
"The exception type was unexpected.");
5、測試運行和管理：
可以使用“測試列表編輯器”來控制想要運行的測試
將光標定位到一個測試方法，運行測試，則會只運行該測試；如果光標位於所有方法前面，則運行當前上下文中(當前類)的所有測試
“測試”菜單--->“測試視圖”--->選中一個測試右鍵--->“屬性”--->可以設置測試的各種屬性。
6、測試結果的觀察分析：
可以查看所有的歷史測試結果，並且可以管理當前正在執行的測試；
測試表單上方的測試總結鏈接，可以統計性的觀察所有測試的執行情況。雙擊具體的測試條目可以看到具體測試的執行結果情況，支持非常豐富的測試記錄信息；
測試條目較多時，可以用不同的“分組依據”來方便的觀察結果，也可以使用測試結果的自定義快速檢索查找感興趣的測試；
右鍵點擊測試，可以看到一個“打開測試”的菜單項，可以方便的定義出錯的測試，進而定位到目標方法；
在測試結果窗體中也可以有選擇的重新執行某些測試；
通過測試報告的時間對比，可以用來做性能調優的一個參照。
7、代碼覆蓋：
該功能只是在VS團隊開發版中才有，專業版中不具備該功能
打開方法：
菜單：測試-->編輯測試運行配置-->選擇你的配置
配置：選中你要做覆蓋率統計的模塊，然後重新執行測試，既可以看到覆蓋率統計結果了
可以詳細解釋被執行代碼的百分率，並用顏色突出顯示哪些代碼被執行，那些沒有被執行。
紅色突出顯示說明了我們有產品代碼沒有運行任何單元測試，這說明我們編寫這些代碼時未遵循 TDD 原則，即在編寫實現前先提供測試。
8、從數據庫中加載測試數據：
提供一個測試值的集合用於驗證實現 ---- 數據驅動測試；
庫的兩種選擇：
文件性：
項目 -> 增加新項-->“本地數據庫”或者“基於服務的數據庫”，然後“工具” ->“ 連接到數據庫”，最後從“服務器資源管理器”修改該庫的結構，如創建表
特點：移植性好，大數據量支持不好
數據庫性：
直接使用服務器資源管理器添加庫
特點：與文件性相反
打開“測試視圖”，選中一個測試編輯其屬性，給他賦予一個數據庫連接的屬性；
設置數據庫連接字符串和連接的測試數據表
這樣做IDE將使用附加的屬性 DataSourceAttribute 和 DataTableNameAttribute 更新自動生成的測試代碼。
使用TextContext的DataRow屬性來訪問你關聯的數據；你不用控制循環遍歷表的內容，由測試框架來自動遍歷表格的每一條記錄；
測試數據的結構
一般包含測試數據本身和預期結果字段兩部分
預期結果可能是一個true或者false的標識
測試數據的組織是十分靈活和講究技巧的
查看測試結果詳細信息時，會發現結果展示為“數據驅動測試結果”
9、測試驅動開發方法的實踐：
在實現類的方法前，先編寫對方法的測試；
然後完善方法，使測試通過，則功能完成。
單元測試的真正價值在代碼修改的時候才真正有所體現，一套單元測試可以保證我們在維護和改進代碼的時候沒有破壞代碼。
在所有現有的開發方法中，TDD 可能是多年來根本上改進開發且投資成本最小的一種。
需要訓練來開始養成習慣，但一旦建立習慣後，不使用 TDD 方法編碼就像開車時不系安全帶一樣。
10、單元測試最佳實踐：
避免測試產生依賴性，這樣測試需要按照特定的順序執行。每個測試都應該是自治的。
避免創建其他依賴計算機的測試，例如依賴特定的目錄路徑的測試。
對於產品代碼中的每個類創建一個測試類。這樣可以簡化測試的組織，並可以容易地選擇在何處放置每個測試。
在繼續創建新的測試前驗證所有測試運行成功，這樣可以保證在破壞代碼後立刻進行修正。
在依賴於手工測試前，必須完全肯定無法采用合理的自動測試方案。
