本文的這一部分將討論在開發(fā)過程中擁有有效工作流程的影響，以及適當(dāng)?shù)臏y試代碼質(zhì)量如何使我們能夠創(chuàng)建可維護(hù)的測試，尤其是對(duì)于復(fù)雜項(xiàng)目。

開發(fā)工作流程和管道

編程是一項(xiàng)流程活動(dòng)，我們開發(fā)人員應(yīng)該對(duì)保持工作流程高效和縮短周轉(zhuǎn)時(shí)間感興趣，以免因等待時(shí)間而分心。

通常，我們要確保測試的總運(yùn)行時(shí)間不超過幾秒鐘，至少對(duì)于我們在“更改-驗(yàn)證-重復(fù)”周期內(nèi)執(zhí)行的所有測試而言。 在開發(fā)過程中，至關(guān)重要的是要對(duì)此周期進(jìn)行快速周轉(zhuǎn)，這涵蓋了從對(duì)項(xiàng)目進(jìn)行一些更改到驗(yàn)證這些更改在類生產(chǎn)環(huán)境中按預(yù)期工作的過程。

如果我們僅通過每次都從頭開始構(gòu)建和部署我們的應(yīng)用程序的管道來進(jìn)行此驗(yàn)證，那就太慢了，無論該管道是否在本地運(yùn)行。 因此，建議創(chuàng)建一個(gè)開發(fā)設(shè)置來偵聽文件更改，然后通過重新部署整個(gè)應(yīng)用程序或更新單個(gè)類或文件來修改應(yīng)用程序以反映我們的代碼更改，然后快速重新執(zhí)行連接的測試方案到更新的被測應(yīng)用程序。 這個(gè)想法是，通常只重新部署應(yīng)用程序或應(yīng)用程序的一部分要快得多，而不是從頭開始啟動(dòng)進(jìn)程并保持潛在的其他本地服務(wù)運(yùn)行。 這種方法使本地運(yùn)行的系統(tǒng)測試變得更加有趣，因?yàn)槲覀兛梢葬槍?duì)正在運(yùn)行的系統(tǒng)重新執(zhí)行測試方案，并立即驗(yàn)證我們的更改。

更具體地說，本地工作流可以是： 重新編譯類，執(zhí)行單元測試，（熱）部署應(yīng)用程序以及執(zhí)行冪等集成測試。 整個(gè)周期不應(yīng)超過一秒或兩秒，否則我們的注意力會(huì)轉(zhuǎn)移到其他地方。 由于集成測試的啟動(dòng)和執(zhí)行時(shí)間，花費(fèi)較長時(shí)間的系統(tǒng)測試或任何其他更復(fù)雜的場景，我們有可能將其拆分為一個(gè)執(zhí)行頻率較低或僅在CI / CD管道中運(yùn)行的單獨(dú)的測試套件。

對(duì)于Java Enterprise項(xiàng)目，請查看WAD或Liberty插件開發(fā)模式 。

測試代碼質(zhì)量和可維護(hù)的測試

導(dǎo)致項(xiàng)目測試不足的最大問題是缺乏可維護(hù)的測試代碼。 在許多情況下，編寫測試，或更確切地說，復(fù)制并粘貼測試，使得一旦對(duì)生產(chǎn)代碼進(jìn)行了較大的更改，就很難更改它們。 這意味著測試代碼通常在處理過程中對(duì)其質(zhì)量的關(guān)注較少。 只要測試用例很少，那就很好。 但是，您通常會(huì)在項(xiàng)目中看到的是，隨著代碼庫變得越來越復(fù)雜，如果我們不應(yīng)用重構(gòu)，則測試套件的可維護(hù)性就會(huì)越來越少，就像生產(chǎn)代碼一樣。

這就是進(jìn)行可維護(hù)的測試的重點(diǎn)：應(yīng)用相同的代碼質(zhì)量原則，尤其是分離關(guān)注點(diǎn)并引入抽象層。 如果要注意不要引入泄漏的抽象，那么在您的測試范圍內(nèi)創(chuàng)建可重用的組件是可行且高度明智的。

讓我們來看一個(gè)進(jìn)一步說明這一點(diǎn)的示例。 我們從有時(shí)被稱為“注釋優(yōu)先編程”的地方開始，在此我們用代碼注釋，偽代碼甚至在紙上書寫，我們的測試場景應(yīng)在純概念，業(yè)務(wù)邏輯層面上驗(yàn)證哪些內(nèi)容。 例如，“創(chuàng)建尺寸較大的Espresso咖啡訂單”。 或者“驗(yàn)證訂單是否在Espresso類型且尺寸較大的系統(tǒng)中 ”。就是這樣。 如何創(chuàng)建訂單不是該級(jí)別的一部分，而是以較低的抽象，單獨(dú)的方法或通常單獨(dú)的委托來實(shí)現(xiàn)。 對(duì)于低級(jí)驗(yàn)證也是如此，例如，檢查是否已發(fā)送回正確的HTTP狀態(tài)代碼和期望的JSON結(jié)構(gòu)。 我們應(yīng)注意不要將僅在詳細(xì)級(jí)別上相關(guān)的信息（例如JSON結(jié)構(gòu)）泄漏給委托方法。

您可以觀看此視頻，以查看實(shí)現(xiàn)該流程的示例流程。 從測試人員或領(lǐng)域?qū)＜业慕嵌葋砜?#xff0c;這種方法很有意義，因?yàn)槲覀冮_始的是要測試的場景，而不是如何實(shí)現(xiàn)。 如果實(shí)現(xiàn)發(fā)生更改，例如與系統(tǒng)的通信從HTTP更改為其他內(nèi)容，則僅需要調(diào)整一個(gè)位置。 此外，我們的測試用例方法變得非常易讀，因?yàn)樗鼈儨?zhǔn)確表達(dá)了要測試的內(nèi)容的概念。 如果我們對(duì)操作方法感興趣，我們會(huì)在較低級(jí)別中找到。

例如，以下系統(tǒng)測試將驗(yàn)證咖啡訂單的創(chuàng)建：

class CreateOrderTest { private CoffeeOrderSystem coffeeOrderSystem; private BaristaSystem baristaSystem; @BeforeEach void setUp() { coffeeOrderSystem = new CoffeeOrderSystem(); baristaSystem = new BaristaSystem(); } @Test void createVerifyOrder() { List<URI> originalOrders = coffeeOrderSystem.getOrders(); Order order = new Order( "Espresso" , "Colombia" ); URI orderUri = coffeeOrderSystem.createOrder(order); Order loadedOrder = coffeeOrderSystem.getOrder(orderUri); assertThat(loadedOrder).isEqualToComparingOnlyGivenFields(order, "type" , "origin" ); assertThat(coffeeOrderSystem.getOrders()).hasSize(originalOrders.size() + 1 ); } ... }

即使他們是非技術(shù)領(lǐng)域的專家，如果他們不了解Java，也可以了解該測試方案的執(zhí)行情況，只要他們了解訂單 ， 咖啡類型和產(chǎn)地的背后領(lǐng)域，并且他們是否愿意忽略Java特定的語法。

這就是為什么我聲稱重點(diǎn)放在測試代碼模式而不是特定的測試框架上的原因。 對(duì)于實(shí)際項(xiàng)目，至關(guān)重要的是引入適當(dāng)?shù)臏y試代碼質(zhì)量，主要是設(shè)計(jì)抽象層并將關(guān)注點(diǎn)分離為委托。 特別是當(dāng)項(xiàng)目變得更加復(fù)雜時(shí)，這種差異會(huì)很快顯示出來。

本系列文章的下一部分將介紹測試框架以及何時(shí)應(yīng)用它們。

翻譯自: https://www.javacodegeeks.com/2019/10/efficient-enterprise-testing-workflows-code-quality.html

總結(jié)

以上是生活随笔為你收集整理的高效的企业测试-工作流和代码质量（4/6）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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