單元測試小技巧

　　確保你的測試寫的越簡單越好，一個單元測試一般不包括一個if switch或者其他任何的邏輯聲明。如果你發現你自己在你的測試中寫了一些類似于邏輯聲明的東西，這是一個好的機會來測試一個以上的事件，在做這樣的操作的時候，你會使得你的測試比讀和維護更加的困難，在生產代碼中同樣如此。保持你的測試簡單，你在生產代碼中發現bug要勝于在你的單元測試中。

　　使測試易于運行  如果你的測試并不容易運行，那么人們不會信任它。你的應用程序最有可能有下面兩種類型的測試：

　　• 測試在沒有任何配置的情況下平穩的運行（這種類型的測試，我們可以在任何的機器上，在代碼的最終版上或者在源控制上測試，并且做到沒有任何故障的測試）
 
　　• 在運行前需要一些配置. 

　　第一種類型是你應該模仿的，第二種類型是你通常做的，尤其你如果你是一個新的單元測試。如果你發現你自己測試時有很多的特殊的需求，現在是正常的，但是重要的一點就是你要隔離出兩個組讓他們能夠單獨的去做測試。

　　我們的想法是任意一個開發者都應該有能力修改和運行一些不需要設置特殊的配置的測試進行測試。如果這有一些測試需要在運行前有特殊的關注，開發者應該知道他們，然后他可以花一些時間學習這些測試的方法。因為很多的開發者比較的懶（當然，不是你），你可以設想，他們不會去做那些特殊的設置，相反，他們會讓測試失敗因為他們有更好的事情去做。

　　當用戶讓測試失敗時，他們開始考慮他們不能夠信任這些測試了。很難說是否測試可以在一個中找到一個正式的bug或者只是一個錯誤的定位。開發者可能不明白為什么測試者會在一開始就執行失敗。一旦他們不再信任你的測試，開發者將會停止運行它們，那么bug就會駐留在程序中，之后一連串的麻煩就來了。。。

　　為了避免這件事情，確認你總是有一個組準備好了去測試，測試程序則是可以安全運行，可信任的。把那些屬于配置挑戰組的測試放到不同的文件夾，樹或者工程中，同時標記特殊的說明指明他們在運行前需要做什么。完成這些后，開發者可以不投入時間去配置就開始測試工作。當他們有時間和需要時，他們也可以配置，運行更多的測試環節。

　　創建維護測試

　　我們應該試著避免測試私有或保護成員。這篇文章也許能夠幫助一些人解決一部分問題，但是我很堅決相信百分之九十九的時間，你可以全面的測試一個類，通過編寫一些與它的獨立公共接口相反的單元測試。測試私有成員可以使你的測試更加脆弱，如果這個需要被測試的類的一些內在方面略有改動的話。你應該使用通過調用一些代碼里別處的公共功能這一方法去測試私有功能。當你依然能夠確定全部功能并沒有改變的時候，僅僅測試公共成員會導致測試遭受常量代碼的因式分解以及內部的執行情況改變。

　　在可能的時候，應該重新使用你的創造物，處理過程，和聲明代碼。不要在一個單元測試中直接的創建類的實例。如果你在任何并不包含在此單元測試框架中的類前面看到這個單詞“new”，你應該考慮一下將你創造的代碼放在一個特殊的整體方法之中，它可以為你創建一個對象實例。你可以到時再重新使用這個方法來獲得你的測試在其他測試之中的最新實例。這樣可以幫助你來保持這個測試維護所需的時間，然后在測試進行的時候，從對代碼無法預料的改變之中保護你的測試。作為一個例子，Figure 1展示了一對簡單的測試，它使用了一個Calc類。

　　假設你有20，或者你甚至有100，與Calc類做相反測試，所有這些看起來令人吃驚的相似?，F在一個計劃的改變迫使你不得不刪除默認的Calc構造器并且使用一個含有一些參數的不同的構造器。馬上，你所有的測試就被暫停了。你可能可以很輕易的發現問題的關鍵并修復它，但你也可能做不到。最主要的問題是你將會浪費很多寶貴時間在修理你的測試上面。如果你在你的測試類之中使用一個整體的方法去創建Calc 實例，就像Figure 2所顯示的那樣，這些就并不是個問題。

　　我已經對測試做了一些改變已使它們能夠具有更多可維護性。首先，我將新創建的代碼遷移至可以再度使用的整體方法之中。這就意味著我只需僅僅改變一個簡單的方法以使得在這個測試類中的所有測試在一個新的構造器中的能夠正常的工作。另外一個為創造問題而設的簡單解決方法是把創作物遷移到測試類的<TestInitialize()>方法之中。不幸運的是，這個能夠很好的工作僅僅在你重新使用一個對象并在一些測試中把它當作一個局部類變量。如果你僅僅為一些測試使用它（部分相關成員），你倒不如在測試中將它們實例化，并且使它們更具易讀性。

　　順便一提的是，請注意，我已經將方法命名為Factory_CreateDefaultCalc 。我很喜歡將我測試中的任何幫助方法用特殊的前綴來命名，這樣我就能很輕易的掌握它是做什么用的。這樣對易讀性也是非常有幫助的。

我的第二個改變是重新使用測試中的聲明代碼，并將這段代碼遷移到一個確認方法之中。所謂確認方法是你測試中的一個可再度使用的方法， 這個方法包含了一個聲明語句但是它可以接受不同輸入和在輸入的基礎上進行校驗。當你在不同輸入或者不同的初始狀態下一次又一次的聲明同一事物時，你可以使用確認方法。這一方法的優點是既使在一個不同的方法里面聲明，如果這個聲明失敗了你將可以繼續保有一個異常處理，而且原始調用測試將會顯示在測試失敗輸出窗口之中。

　　我也在Calc 中傳遞實例而不是使用一個局部變量，因此我知道我經常傳遞一個實例，而且這個實例是調用測試將其初始化的。當你想要改變對象狀態時你可能想要做同樣的事情，舉個例子來說，當在測試下或者在將會傳遞給測試的對象下配置特殊對象時，可以使用特殊的Configure_XX方法。這些方法應該能夠解釋他們配置一個對象將會用來做什么用。Figure 3之中的代碼就是以上方法的實例。

　　這個測試擁有很多設置代碼可以用來處理向注冊管理器對象中添加初始狀態，它是這個測試類之中的成員。在此的確也有一些重復。Figure 4顯示了在初始代碼之外這些事例在因式分解之后將會如何變化。

　　修訂測試具有非常高的可讀性和穩定性。僅僅需要注意的是不要那么的refactor你的測試，他們可能會以一個單一的，不可讀的代碼行作為結束。應該注意的是我在這里可能依然使用一個Verify_XX 方法，但是這并不是我真正要在這里加以說明的。

　　消除測試之間的依賴關系

　　一個測試應該能夠自我獨立。它不應該與其他測試相關聯，也不應該依賴任何具有特殊運行順序的測試，它應該能夠獲得你所寫的所有測試，可以隨意運行所有測試或者只運行其中的一部分，并且是以任何順序，而且要能夠確保它們無論怎樣都應該正確的運行。如果你不能夠執行這個規則，你將會只在某種特殊的情況下按照預期的表現來運行的狀況下結束你的測試。這樣子的話，當你在最終期限下與此同時你還想確定你沒有向系統之中引進新的問題的時候，當然就會出現問題。你可能很困惑而且考慮著是不是你的代碼出現問題，這時，在事實上，問題其實僅僅是你的測試運行順序所引起的。因此，你可能開始錯過了一些在測試中失敗的結果而且使它越寫越少。這將會是個長期的過程。

　　如果你從一個測試調出至另一個測試之中，你應該在它們之間創建一個從屬關系。你本質上說是在一個測試中測試兩個事物（我將會在下一章中解釋為什么這會成為一個問題）。就另一方面來說，如果你有測試B，它與測試A 所產生的狀態是不相關的，那么你會陷入“順序”陷阱之中。如果你或者其他人想要改變測試A，測試B將會暫停而且你不知它暫停的原因。對這些故障進行故障處理會浪費很多時間。

　　使用<TestInitialize()> 和<TestCleanup()>方法是本質上能夠獲得更好的測試隔離。確定你的測試數據時刻是最新的，而且測試下對象的也具有新的實例，而且所有的狀態可以提前預知，而且無論你的測試在任何地方或者任何時間被運行，運行的情況都是相同的。

原文轉自：http://www.anti-gravitydesign.com