讓我們假設我必須開發的下一個功能是將一些資料存盤在資料庫中。按照 TDD 范式，我必須首先撰寫一個失敗的測驗。考慮到我正在使用 JDBC，我不清楚如何處理此任務。我能想到的最簡單的方法是定義一個函式“storeDataOnDB”并使用像 Mockito 這樣的框架檢查該函式是否被呼叫一次。我不喜歡這個解決方案。讓我們繼續 TDD 方法，接下來我將撰寫使測驗通過的最少代碼量。簡單地呼叫該函式將使測驗通過，但我實際上并沒有在資料庫上存盤任何東西。此外，我沒有檢查我是否存盤了正確的資料。
另一種解決方案是使用測驗資料庫實作集成測驗并驗證資料是否正確存盤。但這是一個集成測驗，而在 TDD 中我正在嘗試撰寫一個單元測驗。
那么，在此功能上應用 TDD 的最佳方法是什么？謝謝。
uj5u.com熱心網友回復：
在 TDD 中，我正在嘗試撰寫單元測驗。
你應該放棄這個約束——TDD 不是關于“單元”測驗，不是真的（參見示例測驗驅動開發的第 32 章）。這是關于“程式員”測驗——在撰寫代碼時充當腳手架的小規模測驗。
測驗是為了滿足您的需求，而不是相反。
但是，您應該注意一個技巧：您通常需要一種將復雜邏輯與實際與資料庫通信的部分分開的設計。兩者之間有一個接縫（請參閱有效地使用遺留代碼，第 4 章），允許您為需要與資料庫通信的部分撰寫具有替代實作的測驗。
實際與資料庫對話的部分？理想的代碼是“如此簡單，顯然沒有缺陷”。這里的期望是，如果我們讓代碼變得足夠乏味，那么在我們做對之后就不需要經常更改它（通常這種代碼會一直保持不變，直到它最終被完全洗掉）。
TDD 是對編程期間決策和反饋之間差距的認識，以及控制該差距的技術。
“單元測驗”不是唯一允許的技術。
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/475372.html
上一篇：自定義提供者：物件字面量只能指定已知屬性，并且型別中不存在“提供”
下一篇：柴應該是大數相等不起作用