供給測結(jié)構(gòu)性改革內(nèi)容

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

首先，讓我們嘗試描述我們通常希望跨不同層在應(yīng)用程序中進行測試的內(nèi)容。 讓我們假設(shè)標準的三層體系結(jié)構(gòu)。 在底部，我們有數(shù)據(jù)層。

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

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

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

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

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

所以封裝一切：

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

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

對于基于層的結(jié)構(gòu)，我們的應(yīng)用程序如下所示：

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

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

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

但是通常隨著業(yè)務(wù)邏輯的不斷發(fā)展，它導(dǎo)致將整個應(yīng)用程序拆分為模塊或服務(wù)，因此最終我們得到：

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

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

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

供給測結(jié)構(gòu)性改革內(nèi)容

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。