順便一提的是，請注意，我已經將方法命名為Factory_CreateDefaultCalc 。我很喜歡將我測試中的任何幫助方法用特殊的前綴來命名，這樣我就能很輕易的掌握它是做什么用的。這樣對易讀性也是非常有幫助的。
我的第二個改變是重新使用測試中的聲明代碼，并將這段代碼遷移到一個確認方法之中。所謂確認方法是你測試中的一個可再度使用的方法， 這個方法包含了一個聲明語句但是它可以接受不同輸入和在輸入的基礎上進行校驗。當你在不同輸入或者不同的初始狀態下一次又一次的聲明同一事物時，你可以使用確認方法。這一方法的優點是既使在一個不同的方法里面聲明，如果這個聲明失敗了你將可以繼續保有一個異常處理，而且原始調用測試將會顯示在測試失敗輸出窗口之中。
我也在Calc 中傳遞實例而不是使用一個局部變量，因此我知道我經常傳遞一個實例，而且這個實例是調用測試將其初始化的。當你想要改變對象狀態時你可能想要做同樣的事情，舉個例子來說，當在測試下或者在將會傳遞給測試的對象下配置特殊對象時，可以使用特殊的Configure_XX方法。這些方法應該能夠解釋他們配置一個對象將會用來做什么用。Figure 3之中的代碼就是以上方法的實例。
這個測試擁有很多設置代碼可以用來處理向注冊管理器對象中添加初始狀態，它是這個測試類之中的成員。在此的確也有一些重復。Figure 4顯示了在初始代碼之外這些事例在因式分解之后將會如何變化。
修訂測試具有非常高的可讀性和穩定性。僅僅需要注意的是不要那么的refactor你的測試，他們可能會以一個單一的，不可讀的代碼行作為結束。應該注意的是我在這里可能依然使用一個Verify_XX 方法，但是這并不是我真正要在這里加以說明的。
消除測試之間的依賴關系
一個測試應該能夠自我獨立。它不應該與其他測試相關聯，也不應該依賴任何具有特殊運行順序的測試，它應該能夠獲得你所寫的所有測試，可以隨意運行所有測試或者只運行其中的一部分，并且是以任何順序，而且要能夠確保它們無論怎樣都應該正確的運行。如果你不能夠執行這個規則，你將會只在某種特殊的情況下按照預期的表現來運行的狀況下結束你的測試。這樣子的話，當你在最終期限下與此同時你還想確定你沒有向系統之中引進新的問題的時候，當然就會出現問題。你可能很困惑而且考慮著是不是你的代碼出現問題，這時，在事實上，問題其實僅僅是你的測試運行順序所引起的。因此，你可能開始錯過了一些在測試中失敗的結果而且使它越寫越少。這將會是個長期的過程。
如果你從一個測試調出至另一個測試之中，你應該在它們之間創建一個從屬關系。你本質上說是在一個測試中測試兩個事物(我將會在下一章中解釋為什么這會成為一個問題)。就另一方面來說，如果你有測試B，它與測試A 所產生的狀態是不相關的，那么你會陷入“順序”陷阱之中。如果你或者其他人想要改變測試A，測試B將會暫停而且你不知它暫停的原因。對這些故障進行故障處理會浪費很多時間。
使用
文章來源于領測軟件測試網 http://www.kjueaiud.com/
