邁出單元測試的第一步(2)

　　評審：為了增加測試成功通過的機會，編寫第一個測試時我們應該和同事結對。兩個人都能從實踐中學習，而且我們還能立即評審測試。最好對所測的內容、測試的名稱達成共識，因為這會成為團隊其他人員的基本模板。

　　AAA：現代測試的結構符合AAA模式——Arrange(測試設置)、Act(調用測試里的代碼)、Assert(測試通過的標準)。如果我們使用測試驅動開發(TDD)，我們要先編寫完整的測試，然后再添加代碼。對遺留代碼來說，我們可能需要換一種方式。一旦我們有一個場景和名稱需要測試，那先編寫Act和Assert部分。我們要不停構建Arrange部分，因為對需要準備或仿造的依賴關系，我們知道的要更多一些。然后繼續這么做，直到有一個測試能夠通過。

　　重構：一旦準備好了測試，我們就可以重構代碼了。重構和測試都是后天獲得的技能。我們不僅要重構被測試代碼，也要重構測試本身。但DRY(不要重復自己)原則不適用于測試。測試失敗時，我們希望盡快修復問題，所有的測試代碼最好在一個地方，而不是分散在不同的文件里。

　　可讀性：測試應該是可讀的，最好是人類可讀。和搭檔評審測試代碼，看他能否理解測試的目的。評審其他測試，看看它們的名稱和內容怎樣與相鄰的測試區分開來。一旦測試失敗，就需要修復它們，最好還是在運行失敗之前評審它們。

　　組織：一旦我們有了更多的測試，組織就有了用武之地。測試可以在很多方面有所不同，但最明顯的一個就是如何快速運行。有些測試可能在毫秒內運行完，而有些則需要數秒或好幾分鐘。和工作一樣，我們都希望得到最快的反饋。這就是前面談到的怎么按一定的節奏去進行。要做到這一點，你應該把測試劃分一下，把快的測試和慢的測試分開運行。這能手工(努力)去做，但在.NET領域，Typemock Isolator有一個運行器，能自動按運行速度分離。

　　總結

　　邁出單元測試的第一步是很有挑戰的。體驗依賴的東西很多——語言、工具、現有代碼、依賴關系和技能。只要稍稍思考，進行大量訓練和實踐，你就能漸入測試的佳境。

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