單元測試第三方ORM

Question

我已經閱讀了關於單元測試各種應用程序的有用性的幾個主題。這些意見可以從「一直測試所有事情」到「​​單元測試無用」，以及其間的所有內容（「測試有意義的測試」）。我傾向於向中間傾斜。

這使我想到我的問題。我想，以決定是否將是有益的或實用的有一些基本的單元測試測試的第三方ORM的建議在這種SO帖子： link text

一些基準測試可以作爲對未來的重大更改保險有用，這取決於你如何使用該工具。例如，不是模擬整個n層鏈（我不是在不需要的時候嘲笑），只需使用ORM工具來創建，讀取，更新和刪除一個典型的對象/記錄，並且使用（測試）數據庫上的直接SQL語句驗證操作。這樣，如果第三方供應商稍後更新了某些會破壞其基本功能的內容，並且項目的新開發人員可以很容易地看到如何使用單元測試示例中的ORM工具。

我的主要保留下面這個建議是，它需要太多的設置，將是一個頭痛要維護，總而言之，它不會在我們的環境中實際。下面是一些點的總結考慮：

1. 我們正在使用的ORM需要創建和其數據訪問層註冊，並通過身份驗證的用戶相關聯的靜態數據源對象（S）。這需要大量的測試設置，並且在沒有用戶登錄的構建服務器上可能會出現問題。
2. ORM供應商在發佈新更新和不打破基本功能方面擁有相當不錯的記錄。此外，無論何時何時將ORM更新至最新版本，我都會想到該應用程序不會直接進入生產環境，但是無論如何都會進行徹底的迴歸測試。
3. 在這種環境下維護單元測試的測試數據庫是有問題的。在每個主要發行版之後，測試數據庫將被清除，並使用混淆了敏感數據的分段替換數據庫備份。我會想象爲了有ORM單元測試的測試數據庫，我們需要運行一些腳本/代碼來將數據庫設置爲「測試」狀態。再次設置和維護太多。
4. 最後ORM文檔/幫助新開發人員。我可以看到這樣的事情可能會有用。但是，ORM供應商提供了相當不錯的文檔/幫助演示應用程序。所以編寫單元測試似乎並不值得所有的努力。

那麼，爲了確保ORM完成它應該做的事情（這是CRUD），是否值得去解決所有這些問題？無論如何，它不應該是供應商的責任嗎？

Answer 1

你自己說過。測試它有意義的地方。如果它會讓你「感覺」更好地測試第三方ORM，那就去做吧。但是，最終，你會信任他們的工具。如果ORM突然停止工作，你會怎麼做？你有沒有編寫足夠的代碼來防止它被你輕易地撕掉？你可能會等他們解決它。

基本上，你必須把第三方工具當作俗話說的黑匣子，讓他們做你買他們做的事情。那是你付了錢的原因，對吧？不要自己寫這個。

Answer 2

在這個特殊情況下，我不打擾。我認爲你在這裏承擔了一個糟糕的投資回報是正確的。

是的，我認爲這是供應商的責任。我期望（並承擔）他們的東西的作品。這就是我對待我的供應商的方式。

Answer 3

供應商有責任確保ORM完成它應該做的事情，但是您有責任確保您的應用程序完成它應該做的事情，並且如果它因任何原因失敗，您的客戶將會即使它是「正義的」，因爲ORM失敗，也會不高興。

您的測試可以確保ORM的工作方式與您期望的那樣按照您調用它的方式工作。有可能ORM會以一種不「破碎」的方式進行更改，但與您的應用程序無法很好地協作。這就是說，如果你對ORM充滿信心，並且認爲設置和維護ORM的任何一種自動化測試都不值得花費精力，那很可能不是，特別是如果你有其他級別的話如果出現問題，可能會發現問題。

Answer 4

我個人認爲真正的單元測試應該只測試應用程序本身，並且需要單獨部署和配置的所有東西都應該被模擬出來。

你在說什麼是編寫一些集成/功能測試，測試整個系統的端到端。這些永遠不會是輕量級的，但在某些情況下可能仍然有用（例如，如果您的系統變化不大並且同時對您的公司至關重要）。我也看到了這樣的測試，使用虛擬服務器（VMWare或Microsoft等效軟件）以及在每次測試運行前從文件恢復的示例數據庫。您也可以只設置一次ORM，並接受測試失敗，主要是因爲配置會中斷。顯然你可以測試更多，但要注意成本更高。

Answer 5

測試第三方ORM庫的工作完全不是單元測試。但是，這不是你問題的關鍵。正如在Michael Feathers撰寫的「工作有效地使用遺留代碼」或Eric Evans的「Domain-Driven Design」或Robert Martin的「Clean Code」等書中所說的，您的第三方ORM庫是一項技術應該從您的代碼庫中抽象出來的細節，正是因爲您根據定義無法控制第三方庫。如果他們改變，你可以容納。

所以你的解決方案是圍繞這個ORM庫做一個包裝，理想地將與域相關的接口發佈到應用程序的其餘部分，但通用接口也可能會這樣做。您需要使用完整堆棧自動化測試來測試這個包裝，這必然會將您的應用程序與數據庫以及所需的所有配置和準備一起設置。這個測試不是單元級的，預計會很慢。

您可以在Paul M. Duvall的書「持續集成」第6章中瞭解不同級別的測試以及它們應該如何設置。

當爲應用程序級別編寫真正的單元級別測試時，可以將包裝器模擬到ORM庫上方，因爲您控制包裝器的代碼，因此您可以執行此操作。

這是一個標準做法。它的明顯好處是，當您決定更新ORM庫時（或者極有可能），當您的客戶/老闆決定切換到另一個ORM不兼容的ORM或數據庫時，您將獲得關於ORM庫的即時反饋你的包裝測試中的迴歸錯誤以及你需要做的所有事情都是爲了適應包裝內的變化。順便說一句，「過多的維護負擔」是缺乏自動化造成的謬誤。