我目前正在研究一個使用Struts2框架的項目。我們使用單獨的組件訪問數據庫，這已經過很好的測試。與此同時，我們所從事的項目有很多「行動」，但未經過測試。在大多數操作中，我們至少使用一次DB服務調用。所以一方面這些操作非常簡單。我不確定 - 單元測試是否應該寫入？Struts2行動 - 測試與否？
我認爲最好的做法是始終編寫單元測試，但這些操作非常簡單，而且現在我受到管理方的巨大壓力。那麼，它是否很重要 - 在沒有單元測試的情況下離開Struts2的行爲？
以下是編寫單元測試的三個主要原因。
所以問問自己，這三個編寫單元測試的原因是否適用於此。如果所有三個問題的答案都是「否」，那麼考慮編寫單元測試的代價，並將它們保存在代碼庫中。將此成本與可能的收益進行比較。對你是否應該編寫單元測試做出明智的決定，並且準備好爲你的經理辯護。
但是不要有一個先入爲主的觀點，即「對於每個班級，單元測試總是很好」。不要提出相反的概念 - 「單元測試總是不必要的」。這兩個都不是真的。
必須編寫函數的單元測試可能會有問題，但無論如何，將來可能會驗證的行動，這將是很好的可以測試。 測試操作的時間必須稍微多一點，我建議您這樣做，應用程序中的每一層都必須有一些功能，如果不是不必要的並且必須查看該體系結構。
我和Dhanji Prasanna一樣在Guice和Google Wave工作。它不是100％覆蓋範圍，而是關於編寫有價值的測試，爲正確的組件提供正確的反饋，以幫助開發和防止代碼迴歸。
對於我的一個Struts2應用程序，我們有非常非常複雜的數據驗證要求。數千人。我們使用struts2-junit-plugin在Spring 3 IoC和Struts2驗證的集成上下文中測試動作類，並使用自定義機制爲大量不同的數據場景填充模擬請求。這些測試在開發過程中和作爲維護工具都是非常寶貴的。
但是對於我們一些較簡單的操作，與花費時間寫作相比，我沒有看到太多價值。但是，如果它們非常簡單，它們也不會花太長時間寫出來。
我還看到過100％覆蓋率概念導致100％的課程爲他們寫了毫無思想，毫無價值的測試的情況。對於我的錢，我投票選出了測試將提供最大價值的領域，並專注於做得非常好。
它總是最好的做法，有單位的情況下，如果你有時間，我會強烈建議你去爲他們，而且是S2的簡單架構準備單位案件真的很簡單，旁邊你已經有很好的DB層的情況下。 – 2012-04-15 11:58:34
取決於它們的簡單程度。取決於是否有集成測試會使單獨的操作單元測試變得冗餘。取決於現在要做的最重要的事情。 – 2012-04-15 13:00:17