聲明：本篇博客翻譯自：http://www.c-sharpcorner.com/article/unit-testing-with-ms-tests-in-c-sharp/
寫在翻譯之前：
依然清晰的記得剛工作的第一個項目中，在完成一個功能模塊開發后，師傅讓我把代碼做一下單元測試。當時一臉“懵懂”。心里的疑惑油然而生，測試不應該是測試人員做的嗎？然后就寫了一些測試用例把功能簡單過了一遍。過了幾天后，師傅問我單元測試完成了嗎？我很自信的告訴師傅搞定了。師傅讓我把單元測試的代碼提交到服務器上，他想Review一下！我更加疑惑了，對師傅說，單元測試還要寫代碼呀？:(
前言：
很多初級開發工程師都會有這樣的困惑：誰應該來做單元測試。單元測試應該是由開發者來完成的。
單元測試：
通過一些代碼來測試一個方法/函數的行為。
為什么需要單元測試：
- 通常情況下，一個軟件項目會長期運行/維護/更新，這個時間至少也會有5年的時間；
- 在這期間，維護這個程序非常重要；
- 任何一個代碼的改動都有可能會影響程序的其他功能模塊；
- 因此在更新程序之間，會需要做大量的回歸測試(Regression Testing)，這將花費測試工程師大量的時間。
想象一下如果代碼修改需要非常頻繁，那么花費在回歸測試上的精力會非常多，同樣的，也會有很大的幾率捕捉到功能回退(修改缺陷)的問題。
回歸測試：
回歸測試是確保當增加了新的修改后，老的功能依舊可以正常使用。
單元測試：
- 單元測試將會最小化回歸測試的范圍：
- 每一個方法/函數都會被一系列的測試方法覆蓋，這些測試方法將測試真實方法的功能；
- 測試方法會檢查下面的場景/行為：
- 成功/正常流程
- 失敗
- 異常/錯誤處理
- 一個方法可能需要多個測試方法，這取決於測試方法的復雜度；
- 在代碼交付之前，開發者需要確保所有的測試方法均運行通過。
TDD:
在寫產品代碼之前先寫單元測試代碼，然后使用產品代碼來填充/覆蓋測試代碼。最終使測試代碼都運行通過。
編寫測試用例：
在C#中有2個測試框架
我們使用AAA模式來編寫單元測試
- 安排所以必須的前置條件和輸入；
- 在測試代碼中操作被測試對象和方法；
- 斷言期待的結果；
右擊解決方案瀏覽器，選擇Unit Test Project並添加：
Employee類：
public class Employee
{
public string GetName(string firstName, string lastName)
{
return string.Concat(firstName, " ", lastName);
}
}
單元測試類：
[TestClass]
public class EmpoyeeFunctionalTest
{
[TestMethod]
public void GetNameTest()
{
// Arrange
Employee employee = new Employee();
string firstName = "Jimmy";
string lastName = "Yang";
string expacted = "Jimmy Yang";
string actual = string.Empty;
// Act
actual = employee.GetName(firstName, lastName);
// Assert
Assert.AreEqual(expacted, actual);
}
}
希望上述內容能夠幫助你對單元測試有一個概念性的認識。
感謝您的閱讀！翻譯的不到位之處還望指正。謝謝~