TDD，你有什麼技術可以找到好的測試？

Question

我正在寫一個簡單的Web應用程序，使用Linq to Sql作爲我的數據層，因爲我非常喜歡Linq2Sql。我最近一直在閱讀關於DDD和TDD的一些信息，並希望能夠一蹴而就。

首先，最讓我感到驚訝的是Linq2Sql和DDD不太好。我的另一個問題是找到測試，我發現它很難定義好測試，所以我想問一下，發現好測試用例的最佳技術是什麼？

Answer 1

測試案例發現更多的是一門藝術而不是科學。然而簡單的指導方針包括：

你知道

• 代碼爲體弱/弱/有可能打破
• 按照用戶的場景（你的用戶會做），看看它是如何觸摸你的代碼（通常這意味着調試它，其他時候分析和其他時候，它只是意味着考慮場景） - 用戶觸及代碼中的任何點，這是編寫測試的最高優先級。
• 在您自己的開發過程中，您運行的測試會導致您發現的錯誤 - 編寫測試以避免代碼以相同的行爲再次迴歸。

有關於如何編寫測試用例在那裏的幾本書，但除非你是在一個大的組織，需要記錄的測試用例的工作，最好的辦法是想在你的代碼的所有部分你不要不喜歡（不是「純」），並確保您可以徹底測試這些模塊。

Answer 2

那麼，通過TDD的標準解釋是，測試驅動器您的發展。所以，本質上你是從測試開始的。它會失敗，你會寫代碼，直到測試通過。所以這是由你的要求驅動的，但你要去收集這些東西。你決定你的應用/功能需要做什麼，編寫測試，然後編碼，直到它通過。當然，還有很多其他的技術，但這只是關於TDD世界中典型思想的一個簡短陳述。

Answer 3

我經常爲第三方API編寫測試。這樣，當API更新時，我知道我是否會打破。

Answer 4

認爲。閱讀代碼。自問：例如這個指針可以在這裏永遠不爲NULL嗎？如果在初始化之前調用此方法會發生什麼？

不要做出假設如「這個文件將永遠在那裏」。測試。

想想邊緣的情況下，邊界，負值，溢出...

錯誤往往是由集羣進行分組。當你找到一個時，環顧四周。在其他位置尋找同樣的錯誤。

Answer 5

將您的想法設定爲測試的實際目標：查找錯誤。

在想象什麼可能會導致您的程序失敗時很有創意。

您的測試必須找到錯誤，而不是確認您的程序是否正常。

Answer 6

我認爲這是一個有用的技術：

---

參考：麗莎（陵）劉，伯特蘭·邁耶和 貝恩德·舍勒，使用合同和布爾查詢，提高 質量自動測試生成，在的程序中TAP：測試 和證明，ETH蘇黎世，2007年2月5-6日，編輯。尤里·古列維奇和 伯特蘭·邁耶，計算機科學，Springer- 出版社講義，2007年