單元測試數據庫交互器

我有一個數據庫交互組件，其中包括一個Writer和一個Reader類。 writer類具有諸如insertEntity（Entity）和updateEntity（Entity）之類的寫入方法，而Reader具有諸如getEntityById（EntityId）之類的方法。單元測試數據庫交互器

爲了實現這個組件，我想像平常一樣使用TDD，儘管我不確定如何管理這個組件。如果我從實現Writer開始，如果我還沒有Reader方法，我將如何做有意義的斷言。即使我有Reader方法，我最好不要在Writer的測試中使用它們，儘管也許這是一廂情願的想法。

測試這樣的代碼似乎本質上是一個痛苦，因爲表需要被設置和撕下來。然而，因爲我之前沒有嘗試過爲TDD編寫這樣的代碼，所以我可能會錯過一些技巧來使其相對簡單。任何指針都讚賞。

來源

2013-04-08 Jeroen De Dauw

只要有適當的抽象，就不需要數據庫。

例如，如果我做了一個方法getEntityById，我可以有一個類將使用內存存儲（數組，哈希等）。而我的生產代碼將使用具體實例。在僞代碼中：

 
class MemoryStore 
{ 
    getEntityById(id) 
    { 
     // Return hardcoded response or canned results 
    } 
} 

class DatabaseStore 
{ 
    getEntityById 
    { 
     // Go off to the real database and do reads. 
    } 
}

然後，您可以編寫測試，而不會碰到真正的數據庫。請記住，如果您使用第三方服務，API，數據庫，文件系統等......您不是單元測試。

這裏的另一個好處是，您可以讓另一位開發人員處理數據庫訪問代碼，同時處理其他應用程序。這一切都依賴於「編碼到接口」。

如果要測試數據庫訪問代碼，該怎麼辦？那麼你會想要一個綜合測試。這裏將使用真實的數據庫，並且可以實例化讀取/寫入數據庫的代碼。當然這會很慢並且需要種子數據。重點是你測試這些獨立的，你的其他應用程序將使用內存假貨。所以在上面的例子中，只要DatabaseStore獨立工作，我們可以確信代碼的其他部分是正確的。

來源

2013-04-08 09:15:08 Finglas

我所做的是首先實現我的CREATE方法，然後通過我的DAO的READ方法直接查詢數據庫並且測試這些數據庫，而不是而不是。當這些通過時，你可以使用你的CREATE方法編寫你的READ測試，用測試數據填充你的數據庫，然後實現你的READ方法。

至於在每次測試後建立並拆除數據庫，請將SQL放入您的設置和拆卸方法中。

來源

2013-04-08 09:17:45 mattyB

單元測試數據庫交互器

回答

相關問題