2017-09-27 54 views
3

我已經讀過依賴注入對測試有好處,因爲可以在沒有依賴關係的情況下對類進行測試,但是如果A類依賴於B類或C或任何類,測試類A獨立於某個類正在產生零的測試結果,而不是失敗或過去的測試。是否Java的真的比直接瞭解Java編程更好

A類是爲創建一些東西而創建的,如果在Spring中沒有使用新的關鍵字或設置額外的文件,那麼A類將不會執行任何工作。

關於使代碼模塊化,易讀和可維護的想法:所以業務類變得更加清潔,但我們所做的只是將混淆從髒Java業務類轉換爲複雜的XML文件,並且必須刪除用於注入鬆散對象的接口。

總之,似乎我們必須對某個文件進行編輯和更改,對嗎?

如果我的理解缺乏,請隨時將我放在我的位置,只是因爲學習Spring而有點惱火,因爲我看到重新安排的工作量相同。

+0

你是什麼意思「產生零的測試結果,而不是失敗或過去的測試」? –

+0

我之前沒有進行過單元測試,所以我來自這樣的想法,即當我編寫一個類時,通常需要其他東西來產生任何有意義的結果。我認爲,如果我的課需要一些數據,而且我不會說任何其他課,那麼我的測試沒有給出任何結果,我想如果我寫了任何錯誤,編譯器會好心讓我知道。也許我有不好的設計實踐。 – WPW

+0

如果你只是尋找依賴注入,然後使用普通的簡單設計模式(或類似Guice)。然而,春天是一個爲最小配置提供各種集成組件的生態系統。通過他們我們現在我們贊成通過XML的註釋。 – Rafa

回答

2

依賴注入有助於單元測試,因爲您可以單獨測試每種方法,而不依賴於其他任何方法。這樣每個單元測試就可以測試一種方法。

我會說,如果xml是令人討厭的,那麼請檢查Spring引導。它基於java配置,所以沒有xml,它根據你的類路徑爲你簡化了很多配置。當我第一次開始彈簧時,我發現xml非常令人畏懼來自java背景,但基於註釋的配置和spring引導完成的自動配置對於快速獲取應用程序非常有用。

+0

在Spring Boot中,您可以輕鬆使用模擬框架進行測試,如Mockito。見http://site.mockito.org/ – Twistleton

1

IMO使用彈簧的最大優點是依賴注入,它使您的生活變得輕鬆。例如,如果您想創建一個具有三個依賴關係的新服務,那麼您可以使用Spring輕鬆創建一個類。但是如果沒有彈簧,你最終會寫出不同的工廠方法,這會返回你正在尋找的實例。這使得你的代碼在靜態方法調用時非常冗長。您可能想在春季時代之前查看代碼庫。

同樣,如果您想使用Spring或不是基於項目複雜性的個人調用。但其他特點/優勢不可忽視。

XML文件或Java配置是實現彈簧配置的方式 - 您希望添加業務邏輯的方式是個人風格。唯一的問題是你應該在你的項目中保持一致。

+0

我喜歡你的答案,並且謝謝你。只有一個問題,但是如果存儲庫被java代碼翻轉了那麼配置XML文件怎麼樣也不會變得很大呢?我認爲我感到的是,我們無法消除它在其他地方被推倒的複雜性。我的意思是,如果一個項目真的很大,並且使用Sprimg,XML文件不會變得很大? – WPW

+0

的確如此。如果您使用的舊版本的Spring不支持註釋,那麼您的XML文件將非常龐大。否則,這不是一個大問題。我建議使用Spring的最新版本,以便XML配置問題自動解決。並且你選擇任何版本的spring(舊的或新的),最小的基本配置是不能避免的(xml或Java配置)。只是習慣它而已。而且你在覈心java之上獲得的好處超過了基本的spring配置。 – asg

1

我建議您閱讀Martin Fowler關於Inversion of Control and Dependency Injection的偉大文章,以更好地理解爲什麼像Spring這樣的框架在編寫軟件時能夠解決衆所周知的一組常見的依賴注入問題。

正如其他人所說,沒有義務使用Spring;無論你使用Spring做什麼,你都可以通過抽象工廠,工廠方法或服務定位器等其他方式來完成。

如果你的項目足夠小,那麼你可能不會介意使用上面提到的那些設計模式來自己解決依賴注入問題。但是,根據項目規模的不同,很多人會傾向於使用已經爲這些經常性頭部劃痕器包裝了一堆解決方案的框架或庫。

關於依賴注入框架在進行單元測試時的優點是你不需要測試你的類的依賴關係,而只需要測試你的類。

例如,很可能您的應用程序具有分層設計。有一個數據訪問類或用於從數據源檢索數據的存儲庫是很常見的。從邏輯上講,你也有一個使用該DAO的課程。

很明顯,您已經爲您的DAO編寫了單元測試,因此,當您測試業務類時(使用DAO的位置),您不必再次測試DAO。

幸運的是,由於Spring需要某種形式的DAO依賴注入,這意味着您的類必須提供一個構造函數或setter方法,通過它可以將該DAO注入到我們的業務類中,對嗎?

那麼,在您的業務類的單元測試期間,您可以方便地使用這些注入點來注入您自己的假DAO(即模擬對象)。這樣,您可以專注於業務類的測試,並忘記重新測試DAO。

現在比較這個想法與其他解決方案,你可能已經在你自己做:

  • 您可以直接通過您的業務類中實例化DAO注入的依賴。
  • 您可以在代碼中使用靜態工廠方法來訪問DAO。
  • 您可以使用代碼中服務定位器的靜態方法來訪問DAO。

這些解決方案將使你的代碼易於測試,因爲沒有簡單的方式選擇正是依賴我想注入到我的商務艙,而測試它的方式獲得(例如你怎麼改用於測試目的的靜態工廠方法使用假DAO?)。

因此,在Spring中,使用XML配置或註釋,可以根據許多條件輕鬆地將不同的依賴關係注入到服務對象中。例如,您可能有一些測試配置,顯然與生產中使用的配置不同。如果您有一個臨時環境,您甚至可能會爲您的應用程序提供不同的XML配置依賴關係,具體取決於它是在生產環境還是集成環境中運行。

依賴關係的可插拔性是我認爲的關鍵贏得因素。因此,正如我剛纔所說的,我的建議是,首先擴展您對Spring核心(以及一般所有依賴注入框架)試圖解決什麼問題的理解以及爲什麼它很重要,並且這會給你更廣泛的視角和理解這些問題的方式,你可以確定什麼時候使用Spring是一個好主意,什麼時候不使用。

相關問題