在單元測試中發現失敗的模式

Question

我是單元測試的新手，我只是進入構建測試套件的例程。我有什麼是一個很大的項目，我想從一開始就構建測試。

我想弄清楚構建測試套件的一般策略和模式。當你看一堂課時，顯然由於課堂的性質，很多考試都會出現在你面前。對於具有基本CRUD操作的「用戶帳戶」類，與數據庫表相關，我們將要測試 - CRUD。

• 創建對象，看它是否存在
• 查詢其屬性
• 改變一些屬性
• 變化中的一些屬性值不正確
• ，並再次將其刪除。

至於如何突破東西，有「失敗」共同測試來最CRUD類，如：

• 無效的輸入數據類型
• 甲號碼作爲ID密鑰超出的範圍所選擇的數據類型
• 輸入一個不正確字符編碼
• 輸入太長

依此類推。

對於涉及文件操作的單元測試中，「破事」列表可以在文件名

• 無效字符
• 文件名過長
• 文件名使用不正確的協議或路徑

我非常確定類似的模式 - 適用於目前正在進行的單元測試 - 可以找到大多數正在測試的單元。

現在我的問題是：

• 上午我在看到這樣的 「突破模式」 是否正確？或者我在單元測試方面得到了一些完全錯誤的信息，如果我做得對，這完全不是問題？單元測試是一種尋找儘可能多的方法來打破單元的正確方法嗎？

• 如果我是正確的：是否存在此類模式的現有定義，列表和備忘單？

• 是否有任何規定（主要是在PHPUnit中，因爲這是我工作的框架）使這些模式自動化？

• 是否有任何幫助 - 以檢查列表或軟件的形式 - 幫助編寫完整的測試？

Answer 1

你基本上是對的。尋找可能破壞你的代碼的方法是單元測試的關鍵部分和技巧。但是，在TDD中應用的單元測試工作有點不同。在TDD中，您首先爲新功能編寫測試，然後創建代碼以使測試通過。所以這裏的重點是不同的，儘管最終的結果是相似的。

在TDD中，一個「不斷變化的帽子」 - 一點測試，一點點編碼。所以在這種方法中，測試不是一個可自動化的部分，但人們幾乎可以說它是創作過程的關鍵。在編寫測試時，您還在設計單元的界面，並從其（未來）客戶的角度思考 - 他們可以期待什麼，以及他們應該提供什麼？然後，你換帽子，進入單位，以滿足這些期望。

所以我不覺得這可以通過簡單地檢查列表上的項目來取代。當然，一旦你用完了想法來測試實際單位，檢查這樣的單子從不會感到痛苦。然而，這些表格的性質只能包含可能適用或不適用於特定項目和特定類別的概括。但是你顯然有經驗和思維去爲你的特定單位找到好的測試用例:-)