public void DepositMoneyTest() {
float currentBalance = 500;
BankAccount target = new BankAccount(currentBalance);
float depositAmt = 10;
target.DepositMoney(depositAmt);
Assert.AreEqual(currentBalance + depositAmt, target.CurrentBalance,
"Deposit Test: Deposit not applied correctly");
}
重新生成單元測試代碼
好消息是,代碼生成過程不會讓您重寫以前生成(和修改)的單元測試。使用 Visual Studio 2005 Team System 的 Beta 2 版本,代碼生成選項提供一個啟用/禁用創建已存在測試的復選框。如果選擇它,而且該過程找到了一個具有相同名稱的現有測試,則該過程將忽略該測試方法,并創建后續測試,從而將一個數字附加到該方法名的末尾。這通常在對象中使用重載的方法或構造函數時發生,或者當單擊Generate按鈕而不取消選定現有測試時發生。
自動化單元測試建議
雖然本節可以獨立成文,但這里只是一些您在創建單元測試時可以采納的基本建議。
• |
設計彼此獨立的單元測試,其中它們可以獨立運行(由于可以通過測試 UI 隨意選擇或取消選定它們)。 | ||||
• |
不要只進行正面測試。請確保代碼能夠響應任何方案,包括發生意外時(資源不可用,數據庫只讀等)。 | ||||
• |
把自己當作一個 QA 人員,想象成一個測試人員,而不僅僅是一個開發人員。您花在設計單元測試上的時間將有助于減少日后解決故障所用的時間。請注意對象的幾個小細節:數據如何在對象之間傳輸?誰使用它們?銷毀對象容易嗎?如果我“進行此操作”,將會發生什么? | ||||
• |
跳出您自己的思維模式。盡可能多地對測試進行頭腦風暴。當您完成時,回頭查看您可能漏掉的內容。來自團隊成員的請求反饋 — 例如,他們創建了什么其他類型的測試?其他人可能提供一個對熟悉自己代碼的開發人員而言非常困難的觀點。 | ||||
• |
代碼覆蓋。使用 VSTS 代碼覆蓋規范提供有關每個測試運行中實際執行多少代碼的信息(代碼的行數,占所有代碼的百分比)。如果編碼完成,并且通過了所有測試,但代碼覆蓋顯示只執行了該邏輯的一小部分,那么您的測試真的成功了嗎?高代碼覆蓋不一定意味著您具有一個完整的“測試”集,而未覆蓋的代碼通常非常適用于一個新的測試用例。 | ||||
• |
當生成單元測試時,要幫助其他人了解您的代碼:
| ||||
• |
此外,當其他所有測試都失敗時,請進行調試。自動化單元測試應該有助于減少您用在調試器上的時間。但是,如果測試結果和代碼覆蓋無法提供測試失敗的原因,那么您大可不必擔心調試單元測試。從 Beta 2 版的 Visual Studio 2005 Team System 開始,開發人員可以使用 Test Manager 中的Debug checked tests選項調試他們的單元測試程序集。 |
小結
自動化單元測試為開發環節提供了一個結構化、自行紀錄、高度便攜且可重復的過程。如果在搜索現有程序集,或者如果開發環境需要在開始開發之前進行完整的設計,則請考慮使用內置到 Microsoft Visual Studio 2005 Team System 中的代碼生成引擎。Visual Studio 2005 Team System 的單元測試代碼生成功能可以為您節省寶貴的時間,而且有助于強制團隊的開發標準和約定。通過生成用于自動化單元測試的基本內容,包括生成帶有對象創建的測試方法、參數變量和基斷言類,您應該能夠順利地在您的開發方法論中采用自動化單元測試。
文章來源于領測軟件測試網 http://www.kjueaiud.com/