供給測結構性改革內容

有很多方法可以將整個應用程序分成多個包。 關于按功能或按層打包的優缺點的討論可以在許多編程博客和論壇上找到。 我想從可測試性開始討論這個主題，看看它是否會帶來任何有意義的結果。

首先，讓我們嘗試描述我們通常希望跨不同層在應用程序中進行測試的內容。 讓我們假設標準的三層體系結構。 在底部，我們有數據層。

根據我們對域驅動設計的態度，我們將嘗試最大化（對于豐富的，面向業務的實體）或最小化（對于僅由getter和setter建立的貧乏實體）測試覆蓋率。 在第二種方法中，甚至很難說出任何測試，除非您不信任Java并且想驗證get是否可以檢索set調用之前分配的值。 對于富實體，我們肯定要驗證業務邏輯的正確性。 但老實說，幾乎總是可以通過帶有適當模擬設置的簡單單元測試來完成。 在這一層中通常有成千上萬的測試，因此我們希望它們能最快地完成。 這是單元測試框架的絕佳領域！ 等待？ 您為什么不想使用數據庫測試實體？ 我可以提出相反的問題-我為什么要這樣做？ 要驗證JPA或任何其他持久性API是否仍在工作？ 當然，總會有一些真正復雜的查詢需要在下面的真實數據庫中進行驗證。 對于這些情況，我將在存儲庫級別使用集成測試。 只是數據庫+存儲庫+實體。 但是請記住關于單一責任。 您的集成測試僅檢查查詢-將整個實體邏輯保留給單元測試。

下一步通常是根據服務構建的。 在DDD中，服務僅與存儲庫一起使用以加載實體并委派它們整個業務邏輯處理。 如您所料，這些測試將非常簡單。 您認為我們這里需要數據庫嗎？ 會提供任何附加值嗎？ 不要這樣 那第二種情況呢？ 模型中的貧血實體？ 整個邏輯集中在服務上，因此我們必須在這一層中累積測試覆蓋率。 但是，正如我們已經在域邏輯中討論的那樣，無需使用外部資源就可以完成此操作。 再過一次-我們需要的只是單元測試。 因此仍然沒有數據庫。 我們可以基于存儲庫模擬運行所有測試。 管理數據集沒有問題，不會導致“預期3但發現2”測試失敗。 僅僅是因為其他一些測試又提交了一個價值在200美元到300美元之間的訂單。 即使我們想在這里使用IoC框架，它也可以使用模擬來模擬存儲庫層。 如果不與數據層框架進行適當的解耦，則會通過某種掃描機制自動加載存儲庫。 這不是我們想要的東西。

在服務之上，我們通常放置一些允許用戶使用我們的應用程序的東西。 我們可以使用RESTful API，SOAP服務等作為前端。在這里檢查什么重要？ 與客戶公平起見，我們應該遵守與客戶簽訂的合同。 這對于單獨的博客文章而言可能是重要的，但僅限于REST服務：

“如果您將POST請求發送到/ users URL，我將回答所有用戶的列表。 每個用戶的ID都是整數，帶有用戶名的字符串。”

好的–看起來像是合同。 那么我們應該在這一層檢查什么呢？ 當然，如果這份合同有效。 發送HTTP請求并驗證響應是否包含用戶數組，每個條目都是根據整數ID和字符串用戶名從中構建的。 我們可以在服務模擬的基礎上做到嗎？ 當然可以：)

所以封裝一切：

• 數據層=用于邏輯和與DB的集成測試的單元測試，用于復雜的查詢驗證
• 服務層=用于邏輯和光集成測試的單元測試，無需使用DB用于測試IoC框架相關的邏輯
• 前層=無需DB即可驗證客戶合同的集成測試

到目前為止，我們已經詳細描述了在不同級別上值得測試的內容。 現在，讓我們轉到基于功能的打包。 當圍繞不同的業務環境構建代碼時，絕對有助于使代碼井井有條。 對于大型應用程序，它使您可以將其分解為許多模塊甚至許多應用程序。 如果沒有這樣的功能布局，那么這些動作之前就需要進行大量的重構。 但是在將我們的整體拆分成應用程序之后，仍然需要嗎？ 考慮一下啟動新應用程序。 它的基本包裝是什么？ com.my.company.application ？ 它只不過是功能包：)但是，您會停在此基本包上還是還是分成幾層？ 如您所見，這兩個結構可以一起生活。

對于基于層的結構，我們的應用程序如下所示：

com.company.application\.data\.config\.model\.repository\.service\.config\.api\.config\.controller

對于基于功能的我們會得到類似

com.company.application\.order\.client\.invoice

但是通常隨著業務邏輯的不斷發展，它導致將整個應用程序拆分為模塊或服務，因此最終我們得到：

com.company.application.order\.data\.service\.apicom.company.application.client\.data\.service\.apicom.company.application.invoice\.data\.service\.api

總結一下。 我認為分層包裝是必須的。 它使我們能夠分別測試每一層并保持我們的測試井井有條。 按功能打包在較大的項目中確實很有用。 對于圍繞單個綁定上下文構建的微服務，更詳細的劃分可能會導致導航不舒適。 但是，出于與上述相同的原因，功能包內的代碼仍應在層上斷開。 尤其是基于Spring Framework的基于層的結構，可以幫助我們設置有用的組件掃描，并且不會因為僅僅希望使用兩個服務來啟動上下文而驅使我們設置數據庫。 在我的GitHub存儲庫https://github.com/jkubrynski/spring-package-structure中，您可以找到基于Spring的示例項目。

翻譯自: https://www.javacodegeeks.com/2015/11/smart-package-structure-to-improve-testability.html

供給測結構性改革內容

總結

以上是生活随笔為你收集整理的供给测结构性改革内容_智能包装结构，提高可测性的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。