單元測試小技巧
編寫可維護的節省時間和精力的單元測試
發布日期： 2006-04-17 | 更新日期： 2006-04-17
這篇文章描述了：
| ? |
單元測試的信任
|
| ? |
測試正確事件
|
| ? |
創建維護測試
|
| ? |
創建易讀測試
|
這些天有很多的關于單元測試的和在不同的場景下為他們的應用程序編寫單元測試(起始于, 我們2005年六月的 MSDN?Magazine 中有關測試你的數據層的文章, Know Thy Code: Simplify Data Layer Unit Testing using Enterprise Services)的討論。這些意味著有很多的開發者自言自語（或者對于他們的團隊）到：“哎，我們也需要開始編寫測試了！”因此他們開始編寫單元測試上面的單元測試直到他們達到了一個測試自己已經成為問題的程度。或許維護他們是一個太過困難，花費太長時間，或者他們并沒有足夠的易讀性以便于理解，更或者他們本身存在bugs有一點是能夠使得我們的開發人員可以下定決心去做的，那就是： 花費他們寶貴的時間以用來改進提高他們的測試或者忽略其中的問題, 從而有效的甩掉那些艱苦的工作。而這些困難的原因僅僅是因為那些不熟練的寫入單元測試。.在這篇文章中，我將為大家帶來在過去一年多時間里我在開發，提供咨詢和培訓開發者等方面有總結出來的一些最重要的練習和試驗。這些小的技巧可以幫助您寫出更有效的，可維護，和魯棒性更好的單元測試。同時我希望這些總結和忠告可以幫助您避免一些由于錯誤引起的大量的時間的消耗。
本頁內容
單元測試的信任
在這個部分，我將略述出一些最通用的信任，這些信任來自于在使用大量單元測試獲得的好處和解釋為什么這些信任通常不是必須真實的。然后我們會幫助您在您的工程中擁有這些信任。
更加簡單的跟蹤
Bug? 當然這并不是必須的，那么您怎么知道您的測試是正確的？ 是否存在在一些測試環節測試失敗的情況？另外您又如何知道您的測試覆蓋了系統中多少的代碼量？是否測試到了程序中的錯誤，錯誤又在哪里等等的問題。
當你在你的單元測試中發現了bug后又會發生什么事情哪？你會突然間得到很多與愿意錯誤的反饋，bug被發現，但是問題并不在你測試的代碼中。你的測試的邏輯存在一個bug，因此測試失敗了。這些bug也是您最難被檢查出來的，因為您通常會去檢查您的應用程序而不會去檢測你的測試環節。在這部分中，我會展示給你如何確認大量的單元測試，事實上就是使得跟蹤bug變得更加容易。
代碼更加便于維護?從最終點考慮，你可以傾向于認為這些信任并不是必須的，當然你是對的，讓我們去說，代碼中每個邏輯方法至少要有一個測試方法（當然，你可能擁有一個以上的方法）在一個好的測試覆蓋的工程中，大概有百分之六十的代碼是能夠得到單元測試的，現在不得不考慮到測試也是要被維護的，如果針對一個復雜的邏輯方法你有20個測試，那么當你向這個方法添加一個參數時會發生什么事情哪？測試無法編譯。當你修改了類的結構的時候同樣會發生這樣的事情。這時你突然發現為了能讓你的應用程序繼續工作你自己需要改變大量的測試。當然這會花費你大量的時間。
為了使這個信任確認下來，你需要確認你的測試是便于維護的。保持DRY規則寫入：不要重復你自己。我們將更加接近的來看這個問題。
代碼更加容易被理解? 單元測試的好處通常并非是人們最初所期待的，在一個工程中考慮修改一些你之前從沒有看過的代碼(比方說,一個特殊的類或者方法).你將如何動手處理這些代碼？你可能需要在項目中去瀏覽這些特定的類或者方法使用的代碼，理所當然，單元測試就是這樣例子的一個很好的場所。同時，當正確寫入的時候，單元測試可以為工程提供一個API文件的容易讀取的設置，使得文檔的處理和代碼的理解對于整個團隊中的新老開發者一樣的簡單，便捷。然而，這些只能在測試是易讀的和容易理解的情況下才能被確認，這個規則很多的單元測試開發者并不會遵循。我將詳述這個信任，然后在這篇文章的易讀測試的部分給你展現如何在去寫易讀的單元測試。
測試正確的事情
新來者在Test Driven Development (TDD)中一個最通常的錯誤就是他們通常會搞混"Fail by testing something illogical."中的"Fail first"要求。例如，你可以用下面的規格開始這個方法：
' returns the sum of the two numbers
Function Sum(ByVal a As Integer, ByVal b As Integer) As Integer
你可以向如下的方式寫一個失敗測試：
<TestMethod()> _
Public Sub Sum_AddsOneAndTwo()
Dim result As Integer = Sum(1, 2)
Assert.AreEqual(4, result, "bad sum");
End Sub
初看上去這個處理像是一個寫失敗測試的好的方法，它完全錯失了你寫錯誤測試的初始點。
一個失敗測試驗證了在代碼中存在一些錯誤，當你的測試完成后這個測試應該是通過的，現在的例子中，無論如何，測試都將會失敗，即使是代碼完成，因為測試邏輯上不是正確的。如果希望測試通過測需要測試自身進行修改――而不是程序的代碼的改變（當程序代碼改變的時候，是test-first規劃的意圖）簡短來說，這個測試不會反映出程序代碼完成后的最終的結果，因此這個不是一個好的測試。
TDD中一個好的測試要求你去修改代碼，從而使它能夠按照想要的方式工作，這一點要勝于強迫你去反映現在的真實情況或者一個非邏輯要求的渴望的結果。例如，當1＋1返回0時就意味著測試失敗。這個簡單的例子和這種情況是相似的，在練習中，如果現在的需求是在工作的，測試應該可以反映你所期待的結果，然后你可以調整現在代碼的情況去通過這個測試。
作為一個規則，一個已經調通的測試不應該被移除掉，因為這個測試在維護工作中可以用于恢復測試。他們在你改變代碼時用來確定你沒有損害到現在已經工作的函數。這就是為什么你不應該修改那些已經通過的測試，除非是一些很小的修改，例如增加它的可讀性（換句話說，分解測試）
當一個測試非正常失敗? 有時你可能遇到失敗的測試，而這時你對代碼的改變是完全合理的。這通常是因為你遇到了沖突的需求。一般來說，可能是一個新的需求（一個改變的特性）與一個舊的可能已經不再有效的需求發生了沖突。這有兩種可能：
|
1.
|
在舊的需求或者無效或者在別處測試的情況下刪除被驗證本質上不再有效的失敗的測試
|
|
2.
|
改變舊的測試使你可以測試新的要求（本質上使用新的測試），然后在新的設置下（測試的邏輯狀態相同，但是初始功能函數可能有所不同）測試舊的需求。
|
而有時候一個測試在使用不完整的技術去完成任務的時候也是有效的，例如，你有一個成員類帶有一個FOO方法，它表現為某幾種行為，它已經經由Test在X年前測試完成，然后現在一些其他的需求加了進來，方法的邏輯增強了，從而可以去處理一些類似于在獲取數據時丟失一些參數的異常處理。但這時，突然Test X失敗了，雖然在測試這個函數的時候只是使用了同樣的類。這個測試的失敗是因為在調用方法之前丟失了一些初始處理步驟。
這并不意味著你需要移除Test X，你將丟失對于一些重要功能的測試，這時你應該去關心那些初始化時的問題，而不是改變類的創建以用來適應你新的意圖。
當然如果你那里有200個測試都是因為舊的結構導致的失敗，你就應該找到這個問題來維護你的測試。這就是為什么你應該總是移除你測試中的副本尤其是在生產代碼中。
測試覆蓋和測試
Angles? 你如何知道是否你的新代碼是一個好的覆蓋？當試圖移動一個鏈接或者一個約束檢查后，如果所有的測試依然通過，那么你就沒有足夠的代碼復制然后你可能需要添加其他的測試單元。
確認你添加正確測試的最好方法就是測試一些最平常的行和檢查直到用非常的手段使它出錯。這個也許很難，但是如果你不能考慮出一個讓代碼出錯的方法，你就可能沒有好的理由在最初的地方寫下這行代碼。
你不知道什么時候下一個開發者會試圖運行你的程序，他可能優化或者錯誤的刪除一些包含本質的行。如果你沒有一個測試，它就會失敗，其他的開發者可能不會知道他們犯了錯誤。
你也可能試圖利用一些常量去替代一些已經通過了的測試中調用的各種各樣的參數，例如，看下面的方法：
Public Function Sum(ByVal x As Integer, ByVal y As Integer, _
ByVal allowNegatives As Boolean) As Integer
If Not allowNegatives Then Throw New Exception()
Return x + y
End Function
你可以打亂代碼去測試覆蓋，這有一些關于如何測試的變化：
' Try this...
If Not True Then ' replace flag with const
If x < 0 OrElse y < 0 Then Throw New Exception()
End If
' Or this...
If Not allowNegatives Then
' replace check with const
If False OrElse y < 0 Then Throw New Exception()
End If
如果所有的測試依然通過，那么你缺少了一個測試，另外一個紅色標志是在你為多種相同值測試的檢查。如下：
Assert.AreEqual(3, retval)
一些方法的關系只看一次（在一個測試中）意味著你可以安全的返回3作為一個值，然后所有的針對這個方法的測試都將通過，這個當然意味著你丟失了一個測試。如果你在單元測試中檢查一下代碼，它就很容易被檢查出來。
確保你的測試寫的越簡單越好，一個單元測試一般不包括一個if switch或者其他任何的邏輯聲明。如果你發現你自己在你的測試中寫了一些類似于邏輯聲明的東西，這是一個好的機會來測試一個以上的事件，在做這樣的操作的時候，你會使得你的測試比讀和維護更加的困難，在生產代碼中同樣如此。保持你的測試簡單，你在生產代碼中發現bug要勝于在你的單元測試中。
使測試易于運行? 如果你的測試并不容易運行，那么人們不會信任它。你的應用程序最有可能有下面兩種類型的測試：
| ? |
測試在沒有任何配置的情況下平穩的運行（這種類型的測試，我們可以在任何的機器上，在代碼的最終版上或者在源控制上測試，并且做到沒有任何故障的測試）
|
| ? |
在運行前需要一些配置.
|
第一種類型是你應該模仿的，第二種類型是你通常做的，尤其你如果你是一個新的單元測試。如果你發現你自己測試時有很多的特殊的需求，現在是正常的，但是重要的一點就是你要隔離出兩個組讓他們能夠單獨的去做測試。
我們的想法是任意一個開發者都應該有能力修改和運行一些不需要設置特殊的配置的測試進行測試。如果這有一些測試需要在運行前有特殊的關注，開發者應該知道他們，然后他可以花一些時間學習這些測試的方法。因為很多的開發者比較的懶（當然，不是你），你可以設想，他們不會去做那些特殊的設置，相反，他們會讓測試失敗因為他們有更好的事情去做。
當用戶讓測試失敗時，他們開始考慮他們不能夠信任這些測試了。很難說是否測試可以在一個中找到一個正式的bug或者只是一個錯誤的定位。開發者可能不明白為什么測試者會在一開始就執行失敗。一旦他們不再信任你的測試，開發者將會停止運行它們，那么bug就會駐留在程序中，之后一連串的麻煩就來了。。。
為了避免這件事情，確認你總是有一個組準備好了去測試，測試程序則是可以安全運行，可信任的。把那些屬于配置挑戰組的測試放到不同的文件夾，樹或者工程中，同時標記特殊的說明指明他們在運行前需要做什么。完成這些后，開發者可以不投入時間去配置就開始測試工作。當他們有時間和需要時，他們也可以配置，運行更多的測試環節。
創建維護測試
我們應該試著避免測試私有或保護成員。這篇文章也許能夠幫助一些人解決一部分問題，但是我很堅決相信百分之九十九的時間，你可以全面的測試一個類，通過編寫一些與它的獨立公共接口相反的單元測試。測試私有成員可以使你的測試更加脆弱，如果這個需要被測試的類的一些內在方面略有改動的話。你應該使用通過調用一些代碼里別處的公共功能這一方法去測試私有功能。當你依然能夠確定全部功能并沒有改變的時候，僅僅測試公共成員會導致測試遭受常量代碼的因式分解以及內部的執行情況改變。
在可能的時候，應該重新使用你的創造物，處理過程，和聲明代碼。不要在一個單元測試中直接的創建類的實例。如果你在任何并不包含在此單元測試框架中的類前面看到這個單詞“new”，你應該考慮一下將你創造的代碼放在一個特殊的整體方法之中，它可以為你創建一個對象實例。你可以到時再重新使用這個方法來獲得你的測試在其他測試之中的最新實例。這樣可以幫助你來保持這個測試維護所需的時間，然后在測試進行的時候，從對代碼無法預料的改變之中保護你的測試。作為一個例子，Figure?1展示了一對簡單的測試，它使用了一個Calc類。
假設你有20，或者你甚至有100，與Calc類做相反測試，所有這些看起來令人吃驚的相似。現在一個計劃的改變迫使你不得不刪除默認的Calc構造器并且使用一個含有一些參數的不同的構造器。馬上，你所有的測試就被暫停了。你可能可以很輕易的發現問題的關鍵并修復它，但你也可能做不到。最主要的問題是你將會浪費很多寶貴時間在修理你的測試上面。如果你在你的測試類之中使用一個整體的方法去創建Calc 實例，就像Figure?2所顯示的那樣，這些就并不是個問題。
我已經對測試做了一些改變已使它們能夠具有更多可維護性。首先，我將新創建的代碼遷移至可以再度使用的整體方法之中。這就意味著我只需僅僅改變一個簡單的方法以使得在這個測試類中的所有測試在一個新的構造器中的能夠正常的工作。另外一個為創造問題而設的簡單解決方法是把創作物遷移到測試類的<TestInitialize()>方法之中。不幸運的是，這個能夠很好的工作僅僅在你重新使用一個對象并在一些測試中把它當作一個局部類變量。如果你僅僅為一些測試使用它（部分相關成員），你倒不如在測試中將它們實例化，并且使它們更具易讀性。
順便一提的是，請注意，我已經將方法命名為Factory_CreateDefaultCalc 。我很喜歡將我測試中的任何幫助方法用特殊的前綴來命名，這樣我就能很輕易的掌握它是做什么用的。這樣對易讀性也是非常有幫助的。
我的第二個改變是重新使用測試中的聲明代碼，并將這段代碼遷移到一個確認方法之中。所謂確認方法是你測試中的一個可再度使用的方法， 這個方法包含了一個聲明語句但是它可以接受不同輸入和在輸入的基礎上進行校驗。當你在不同輸入或者不同的初始狀態下一次又一次的聲明同一事物時，你可以使用確認方法。這一方法的優點是既使在一個不同的方法里面聲明，如果這個聲明失敗了你將可以繼續保有一個異常處理，而且原始調用測試將會顯示在測試失敗輸出窗口之中。
我也在Calc 中傳遞實例而不是使用一個局部變量，因此我知道我經常傳遞一個實例，而且這個實例是調用測試將其初始化的。當你想要改變對象狀態時你可能想要做同樣的事情，舉個例子來說，當在測試下或者在將會傳遞給測試的對象下配置特殊對象時，可以使用特殊的Configure_XX方法。這些方法應該能夠解釋他們配置一個對象將會用來做什么用。Figure?3之中的代碼就是以上方法的實例。
這個測試擁有很多設置代碼可以用來處理向注冊管理器對象中添加初始狀態，它是這個測試類之中的成員。在此的確也有一些重復。Figure?4顯示了在初始代碼之外這些事例在因式分解之后將會如何變化。
修訂測試具有非常高的可讀性和穩定性。僅僅需要注意的是不要那么的refactor你的測試，他們可能會以一個單一的，不可讀的代碼行作為結束。應該注意的是我在這里可能依然使用一個Verify_XX 方法，但是這并不是我真正要在這里加以說明的。
消除測試之間的依賴關系
一個測試應該能夠自我獨立。它不應該與其他測試相關聯，也不應該依賴任何具有特殊運行順序的測試，它應該能夠獲得你所寫的所有測試，可以隨意運行所有測試或者只運行其中的一部分，并且是以任何順序，而且要能夠確保它們無論怎樣都應該正確的運行。如果你不能夠執行這個規則，你將會只在某種特殊的情況下按照預期的表現來運行的狀況下結束你的測試。這樣子的話，當你在最終期限下與此同時你還想確定你沒有向系統之中引進新的問題的時候，當然就會出現問題。你可能很困惑而且考慮著是不是你的代碼出現問題，這時，在事實上，問題其實僅僅是你的測試運行順序所引起的。因此，你可能開始錯過了一些在測試中失敗的結果而且使它越寫越少。這將會是個長期的過程。
如果你從一個測試調出至另一個測試之中，你應該在它們之間創建一個從屬關系。你本質上說是在一個測試中測試兩個事物（我將會在下一章中解釋為什么這會成為一個問題）。就另一方面來說，如果你有測試B，它與測試A 所產生的狀態是不相關的，那么你會陷入“順序”陷阱之中。如果你或者其他人想要改變測試A，測試B將會暫停而且你不知它暫停的原因。對這些故障進行故障處理會浪費很多時間。
使用<TestInitialize()> 和<TestCleanup()>方法是本質上能夠獲得更好的測試隔離。確定你的測試數據時刻是最新的，而且測試下對象的也具有新的實例，而且所有的狀態可以提前預知，而且無論你的測試在任何地方或者任何時間被運行，運行的情況都是相同的。
在一個單獨單元測試中避免多重聲明
我們將聲明故障看作一個程序弊病的象征且聲明被當作軟件體的指示點或者“血液檢查”。你可以找到越多的癥狀，程序弊病就越可以輕松的被診斷和排除掉。如果你在一個測試中定義了多重聲明，只有第一個故障聲明將會以拋出異常的方式顯示出來。請參考下面插圖之中的測試代碼：
<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 可能非常的長，它可能會使你的聲明行延伸出屏幕的邊緣之外，這樣導致測試者向右滾屏。就我個人而言，我認為這個是非常惱人的。
我在我的測試中使用了很多常量以確保我的聲明讀起來像一本書。在先前的例子之中，你可以讀到聲明中說：“確保分解總數是與忽略第一個數后所得總和是相等的。” 為你的變量取一個很好的名字能夠在某些程度上彌補對于測試的命名不足。
當然，有時一個聲明 消息是在一個單元測試中傳遞intent的最好的方法。 一個好的聲明消息始終能夠解釋什么因該會發生或者什么發生了而且為什么會出錯。舉個例子來說，“分列應該忽略掉第一個數字如果這個數字是個負數的話”，“分列不能夠忽略掉第一個負數”，還有“X調用對象Y標記錯誤”這些都是有用的聲明消息，它們很清晰的描述了結果的情況。
在你的設置方法中避免部分相關的代碼
一個<TestInitialize()> 方法是樣例成員變量在測試中使用的一個好地方。你所有的測試，只有在一部分的測試中避免變量。他們可以為測試設置本地變量。如果你創建了部分相關的實例作為類的成員，用來在測試中簡單的避免創建的副本，你應該使用在文章前面解釋的工廠方法，使用部分相關變量使得你的代碼和設置方法缺少易讀性。一旦變量在一個或者每個測試中使用，那么他應該是<TestInitialize()> 方法的一個成員和變量。
Figure?5
展現了一個擁有兩個成員變量的類的測試。但是他們中的一個(cxNum)只被部分使用。Figure?6 展現了如何在測試中替換代碼從而使它更加易讀的方法。
總結
就像你所看到的，寫單元測試并不是一個微不足道的任務，如果步驟正確，單元測試可以為開發者的生產力和代碼的質量帶來令人驚訝的提高，他可以幫助你去創建的應用程序含有更少的錯誤，同時也可以便于其他的開發者去洞察你的代碼，但是他也需要在之前承擔一個義務，確認遵循一些簡單的規則。當方法并不是很好時，單元測試則可能達到一個相反的結果，從而浪費您的時間，并且使測試過程更加復雜。
Roy Osherove Agile組的負責人, 這個顧問公司致力于agile software development 和 .NET architecture的研究工作. Roy同時維護了一個blog在 www.iserializable.com上有相關的信息. 你可以通過Email聯系他： Roy@TeamAgile.com.
轉到英文頁面