集成測試最佳實踐

Question

我工作的一個項目，面臨

我創建的類中的方法找到了一些用戶和應用邏輯下面的問題，這將引發一些意想不到返回其他用戶對象要麼異常id null或有一些值

我寫了所有測試用例的單元測試，現在在被調用者中，我忘記了爲null id添加條件。

處理這類錯誤的最佳做法是什麼？我應該用所有測試用例編寫集成測試還是集成測試應該只有快樂的路徑？

其次，在集成測試中，使用嵌入式數據庫代替實際的數據庫是否好？我正在考慮使用嵌入式數據庫進行集成測試，但是我如何測試供應商特定的查詢，例如oracle中的rownum和mysql中的限制。在我的實際環境中，我們使用的是oracle和嵌入式數據庫，我可以使用h2。我使用普通的JDBC

感謝

Answer 1

這是我會爲供應商特定的情況下做的 - 因爲在甲骨文rownum和limit在MySQL兩限行數回來後，我會在我的身邊創造一個抽象，說，myLimit。根據供應商數據庫的選擇，它會映射到rownum或limit。

一旦你有了上述和任何其他必要的抽象涵蓋了你的應用程序的所有方面，你可以開始設計集成測試。我建議的首選項是：（i）所有供應商的實際數據庫連接，（ii）嵌入式數據庫和（iii）模擬數據庫。數據庫本身並不需要很大。

基於質量保證指標，如果您認爲數據庫連接已經通過其他測試完全測試，那麼我會在集成測試中使用嵌入式或模擬數據庫。

正如您所看到的，答案取決於系統其餘部分的測試情況！祝你好運。

Answer 2

關於單元和集成測試。

讓我們來澄清這些類型的測試之間的區別。

單元測試應當覆蓋單元，其意味着我們覆蓋相當小塊代碼。因此，單元測試通常涵蓋非常特定的情況，通常有很多單元測試，因爲對於一個小的方法，程序可能有幾個方向，所有這些都應該被覆蓋。所有令人不安的事情單元測試，比如說，有些方法是調用外部方而沒有真正涉及到方法的業務邏輯必須嘲笑。

在集成測試，而不是因爲你要測試整個管基本上，這意味着你的測試應該通過不同的模塊（類），不要嘲笑任何它是不可取的嘲笑什麼。這種類型的測試通常是相當大的，因此，我會建議而不是來處理集成測試中的一些小的驗證檢查，因爲從我的角度來看，這不值得這樣做。

如果我從我的角度正確理解你的情況，你的方法應該檢查null而不是調用者。這是基於你不知道誰會打電話給你的方法。 您的方法應該預計允許輸入參數中的所有不同值。