.NET中的代碼契約，測試，斷言和異常，何時使用？

Question

首先，我想承認，我明白這些是與他們自己的宗旨領域不同的概念。

有人說，我偶爾會發現自己想知道處理某些事情的最佳方式是使用合同，良好的測試還是在使用不當的情況下發生異常。

舉例來說，諸如健全性檢查和驗證等非平凡的輸入要求是那些合同領域還是它們更好地被例外處理？如果它們不是特殊的，但僅僅是針對設計呢？如果他們不會導致不可預知的行爲，但只有潛在的不良或「驚人的」行爲呢？你可以爭辯說，這種設計模糊性是一種代碼味道，但有時至少就實用主義而言，它是不可避免的。

我想知道是否有人有這個主題，他們願意提供的指導方針？

Answer 1

對於由最終用戶控制的代碼輸入引起的不正確輸入，合同不應該是失敗模式。開發過程中只能接受合同失敗。在生產過程中，合同失敗可以記錄下來供開發人員進一步檢查。所以如果你的輸入需要驗證，驗證它，不要讓合同失敗。這就是說，如果你建立一個庫，並且你的輸入來自其他開發者編寫的代碼，那麼契約是告訴另一個開發者輸入不可接受的好方法。

Answer 2

我認爲這一切都取決於你試圖完成的測試。實際上，我比其他任何事情都更多地使用契約和斷言。作爲一般規則，測試絕不應該通過try/catch塊引發異常。相反，你應該更加離散地處理異常，例如，封裝它，然後在另一個獨立於你的測試類的類中處理它。

使用合同是爲測試設置先決條件以使其更加專注的好方法。正如我已經提到的那樣，我使用這些並聲稱比什麼都重要。通過我們的框架（Selenium WebDriver），在辦公室裏，我們使用'@Test'來標記這是一個測試，然後通過調出它適合的'bucket'來讚美它，如@Category(SomeTestClass.class)。

使用斷言時，請記住您使用的是哪種類型。一些停止代碼執行，而其他人允許「通過」（很像在switch/case聲明中）。另外，在使用它們時，我們嘗試設置斷言，以便以True條件結束，而不是錯誤條件。就像這樣：

assertTrue("Product breadcrumbs not showing", productCQPage.areBreadCrumbsShowing()); 

在上面的例子中，我使用了一個布爾值，以驗證是否麪包屑都出現與否，在這種情況下，斷言纔會觸發如果布爾返回false。再次，我進入一個消極的，但主張積極的。令人困惑，對吧？ :)

我希望這在某種程度上對你有幫助！