模板
教程
環境
性能
功能
管理
單元測試小技巧(5)
在一個單獨單元測試中避免多重聲明
我們將聲明故障看作一個程序弊病的象征且聲明被當作軟件體的指示點或者“血液檢查”。你可以找到越多的癥狀，程序弊病就越可以輕松的被診斷和排除掉。如果你在一個測試中定義了多重聲明，只有第一個故障聲明將會以拋出異常的方式顯示出來。請參考下面插圖之中的測試代碼：
|
<TestMethod()> _ Public Sub Sum_AnyParamBiggerThan1000IsNotSummed() Assert.AreEqual(3, Sum(1001, 1, 2) Assert.AreEqual(3, Sum(1, 1001, 2) ' Assert fails Assert.AreEqual(3, Sum(1, 2, 1001) ' This line never executes End Sub |
你可能沒有發現以上代碼之中其他可能的征兆。在一個故障之后，并發的聲明不會被執行。這些不能生效的聲明可能提供了有價值的數據(或者征兆)可能能夠幫助你很快的集中的焦點而且發現潛在的問題。因此在一個獨立的測試中運行多重聲明增加了具有很少價值復雜性。另外，聲明應該被獨立的運行，我們應該設置自我獨立的單元測試以使得你具有能夠很好的發現錯誤的機會。
返回頁首
創建易讀性測試
如果你以前寫過單元測試，你是否在單元測試上寫了一個好的聲明行?可許不是這樣的，大多數開發者并不厭煩去寫一個好的聲明因為他們更加關心去寫測試。
假設你是團隊中的一個新的開發者，你試圖讀一個單元測試。連接這個：
|
<TestMethod()> _ Public Sub TestCalcParseNegative() Dim c As New Calc Assert.AreEqual(1000, c.Parse("-1, -1000") End Sub |
作為一個簡單的練習，如果你理解了上例中Calc分列方法的用法，你很可能可以進行很好的推測，但是他可以簡單的作為人員數量的用例使得輸出結果為1000:
在組中返回最大的負數作為一個正數。
如果數字是負數且返回值為剩下幾個數的總和作為一個正數，那么忽略第一個數字。
返回相互作乘積運算而得的數字。
現在請參考下面在單元測試之中的小改動：
|
<TestMethod()> _ Public Sub Parse_NegativeFirstNum_ReturnsSumOfTheRestAsPositive() Dim c As New Calc Dim parsedSumResult As Integer = c.Parse("-1", "-1000") Const SUM_WITH_IGNORED_FIRST_NUM As Integer = 1000 Assert.AreEqual(SUM_WITH_IGNORED_FIRST_NUM, parsedSumResult) End Sub |
這個是不是比較容易理解呢?當聲明消息消失之后，表達意圖最合適的地方就是測試的名字。 如果你廣泛的使用了它，你將會發現你不再需要讀測試代碼就能明白代碼測試的目的所在。事實上，你經常根本不需要寫任何注釋，因為代碼，特別是那些帶著實例的，他們自己是證明自己的。
名字包含了三部分內容： 測試下方法的名字(解析)，測試下的狀態或者規則(帶著第一個負數傳遞一個字符串)，以及預期的輸出或者運行情況(剩余數字的總和以一個正數的形式返回)。需要注意的是我從名稱中將Test以及Calc這兩個詞刪除。我已經知道這是一個屬性的測試因此在此沒有重復此信息的必要。我也知道這是一個在 Calc類中的測試因為測試類經常是寫給一個特殊類的(這個類也許已經被命名為CalcTests)。
名字也許會很長，但是又有誰在乎呢?它讀起來更像是一個標準英語的句子而且它使得一個新來的開發者更容易明白測試的內容。更是這樣，當這個測試發生故障時，我們甚至不需要調試代碼就可以知道問題究竟出在哪里。
需要注意的是，我已經在前面分別實際演示了通過在不同行中創建一個結果變量的方法從聲明操作中進行分解操作。這樣做至少有兩個理由。第一個理由是，你可以為一個變量分配一個可讀性強的名字，它可以包含結果，這樣可以使你的聲明行非常易于理解以及易于讀。第二點是，測試下與對象相反的invocation 可能非常的長，它可能會使你的聲明行延伸出屏幕的邊緣之外，這樣導致測試者向右滾屏。就我個人而言，我認為這個是非常惱人的。
我在我的測試中使用了很多常量以確保我的聲明讀起來像一本書。在先前的例子之中，你可以讀到聲明中說：“確保分解總數是與忽略第一個數后所得總和是相等的。” 為你的變量取一個很好的名字能夠在某些程度上彌補對于測試的命名不足。
原文轉自：http://www.uml.org.cn/Test/200605091.htm
