修訂測試具有非常高的可讀性和穩定性。僅僅需要注意的是不要那么的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

更多軟考資料請訪問：考試吧軟件水平考試欄目

希望與更多網友交流，請進入考試吧軟件水平考試論壇