本文的這一部分將討論在開發過程中擁有有效工作流程的影響，以及適當的測試代碼質量如何使我們能夠創建可維護的測試，尤其是對于復雜項目。

開發工作流程和管道

編程是一項流程活動，我們開發人員應該對保持工作流程高效和縮短周轉時間感興趣，以免因等待時間而分心。

通常，我們要確保測試的總運行時間不超過幾秒鐘，至少對于我們在“更改-驗證-重復”周期內執行的所有測試而言。 在開發過程中，至關重要的是要對此周期進行快速周轉，這涵蓋了從對項目進行一些更改到驗證這些更改在類生產環境中按預期工作的過程。

如果我們僅通過每次都從頭開始構建和部署我們的應用程序的管道來進行此驗證，那就太慢了，無論該管道是否在本地運行。 因此，建議創建一個開發設置來偵聽文件更改，然后通過重新部署整個應用程序或更新單個類或文件來修改應用程序以反映我們的代碼更改，然后快速重新執行連接的測試方案到更新的被測應用程序。 這個想法是，通常只重新部署應用程序或應用程序的一部分要快得多，而不是從頭開始啟動進程并保持潛在的其他本地服務運行。 這種方法使本地運行的系統測試變得更加有趣，因為我們可以針對正在運行的系統重新執行測試方案，并立即驗證我們的更改。

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

對于Java Enterprise項目，請查看WAD或Liberty插件開發模式 。

測試代碼質量和可維護的測試

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

這就是進行可維護的測試的重點：應用相同的代碼質量原則，尤其是分離關注點并引入抽象層。 如果要注意不要引入泄漏的抽象，那么在您的測試范圍內創建可重用的組件是可行且高度明智的。

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

您可以觀看此視頻，以查看實現該流程的示例流程。 從測試人員或領域專家的角度來看，這種方法很有意義，因為我們開始的是要測試的場景，而不是如何實現。 如果實現發生更改，例如與系統的通信從HTTP更改為其他內容，則僅需要調整一個位置。 此外，我們的測試用例方法變得非常易讀，因為它們準確表達了要測試的內容的概念。 如果我們對操作方法感興趣，我們會在較低級別中找到。

例如，以下系統測試將驗證咖啡訂單的創建：

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 ); } ... }

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

這就是為什么我聲稱重點放在測試代碼模式而不是特定的測試框架上的原因。 對于實際項目，至關重要的是引入適當的測試代碼質量，主要是設計抽象層并將關注點分離為委托。 特別是當項目變得更加復雜時，這種差異會很快顯示出來。

本系列文章的下一部分將介紹測試框架以及何時應用它們。

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

總結

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

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