單元測試EJB 3.1 - 爲什麼模擬容器服務

Question

在EJB 3.1的單元測試中模擬容器服務有什麼優勢？

的可能答案，我是說我想它是，

1. 它提高了測試的性能。
2. 它不遵守單元測試的規則，因爲與其他API有很多交互。 （請提供您的意見）

除了這些，你認爲還有其他的優點嗎？可以測試一些由容器提供的服務，比如持久性，事務管理（比如使用Bitronix），消息傳遞（例如使用Apache ActiveMQ和內存中的JNDI）在您自己的JVM中的容器之外。仍然有一種觀點認爲它是集成測試，單元測試不應該這樣做。

根據我的說法，如果你在測試中可以獲得良好的性能，那麼使用這些第三方實現進行單元測試是很好的，因爲你不必花費太多的時間在嘲笑中，嘲笑嚴重依賴於開發人員錯誤。如果一個開發人員對嘲笑不甚瞭解，他最終可能會嘲笑一切，或者換句話說，誤用嘲弄將測試變成「綠色」。這是正確的嗎？ （請提供您對此的看法）

畢竟，我從來沒有得到任何固體單元測試的定義:-)。這取決於作者。一些人將「單位」定義爲可以測試的最小單位，而另一些則定義爲「根據具體情況，這些可以是單個子程序或由緊密相關單位組成的更大組件。」

謝謝。

Answer 1

如果您有使用容器服務的代碼，然後對其進行測試，則需要模擬這些服務或使用真實的實現。你必須做一個或另一個：沒有一些執行的服務，你的代碼不會運行，所以不能被測試。

有時，您可以重構代碼以刪除對容器服務的直接依賴關係，這也將消除模擬這些服務的需要。但不總是。

模擬容器服務比使用真正的實現提供更多的隔離。它還使您能夠更好地控制和深入瞭解代碼的執行情況。但是，它也涉及編寫更多的代碼，並且帶來更多的引入錯誤的風險（mock中的錯誤，可以直接轉化爲應用程序代碼中的錯誤）。

有時候嘲諷肯定是有道理的。例如，如果您想編寫一個測試來檢查您的代碼是否在UserTransaction上進行了正確的調用，那麼通過模擬比通過試驗真實事務監視器更容易。如果您想編寫一個測試來檢查代碼是否正確處理特定的SQLException，那麼沒有模擬就幾乎是不可能的。

除了這些情況，正如您指出的那樣，可以使用真實服務編寫測試，或者嘲笑它們。正如我認爲你已經意識到的那樣，傳統的單元測試方法是嘲笑它們，或者事實上，將它們包裝起來，然後模擬包裝。

無論這實際上是必要的還是一個好主意，都非常容易爭論。

StackOverflow不應該是主觀問題，或辯論或討論，所以我猶豫在我的意見。我只想說這與我認爲自己是一樣的 - 正統的「模擬所有移動的方法」是不必要的，也是有害的，我們會用更少的嘲諷編寫測試，覆蓋更大的真實代碼區域會好得多。畢竟，真正的代碼就是我們要發佈給用戶的，所以爲什麼不測試它呢？