設計優先世界的 API 契約測試(合約測試)
如今，API 驅動的微服務應用程式是創新速度和競爭優勢的來源－根據 SmartBear 最新的軟體品質狀況－API 報告：
- API 正成為核心內部業務功能的中心：70% 的受訪公司開發 API 的時間已超過三年。
- 在這群人中，近四分之三的組織自行使用和開發API，其中兩個最受歡迎的驅動因素是 (1) 減少開發時間和成本，以及 (2) 內部系統、工具和團隊之間的資料互通與交換。
然而，這種現代的軟體架構方式並非沒有挑戰。 如果 API 的設計和測試忽略了使用新的方式來適應新的服務架構設計，這可能會使一切努力付諸東流。 問題的關鍵在於 API 設計定義與現實的偏離。這可以從整合中的任何一個點發生；例如，提供者可能沒有實際實作 API 定義。又或是，使用者可能會誤解提供者的要求，因此我們會看到誤解和整合問題，或者團隊忽略設計的 API 定義，導致過時的、不相關的文件。 漂移（Drift：偏離原設計）會對軟體開發生命週期造成負面影響，通常只能在稍後才發現－而且通常是在程式碼變更被推送到開發或暫存環境之後……或者有時是更後面。在後期階段發現錯誤的工作相對困難許多，也因此這往往會大幅增加整體開發時間（開發＋除錯／重新開發）。 在這篇部落格中，我將討論「設計優先」的API 契約測試的概念，作為微服務軟體開發的新最佳實踐方法－將健全的API 標準和治理框架與全面的API 測試方法相結合，使各種規模和設定的團隊能夠擴展快速交付高品質軟體。
API 設計優先（Design-First）方法簡介
簡而言之，API 設計優先的方法就是使用相同的語言。這種高度流行的方法提倡在編寫任何程式碼之前預先設計 API 規範，並以人類和電腦都能理解的方式記錄下來。 有些人可能會認為這種方法速度較慢。然而，如果我們思考範圍不僅只有軟體開發生命週期 (SDLC) 的 API 設計方面，我們就會發現預先調整 API 設計對於整體交付速度反而是更快的！
設計優先方法的好處
將設計優先的方法視為設計和開發之間的橋樑。好處包括：
- 讓產品經理和 QA 參與建立以產品為中心的 API，稱為產品驅動的 API
- 使開發人員能夠使用 API 設計和自動化工具來加速開發工作
- 跨職能團隊－允許 API 使用者、生產者和技術編寫者平行工作
- 設計的可見性和更短的回饋循環
- 在部署到 Production 之前驗證實施，讓 DevOps 角色更容易
- 在整個開發過程中適應變化的能力，越到專案後期影響越大
- 降低規範偏離實施的風險
設計優先的方法何時合適？
高績效組織在以下情況下選擇設計優先的 API 開發方法：
- 開發人員經驗很重要。
- API 的交付是關鍵任務。
- 溝通和協調至關重要。
現在，許多人也選擇它來支援 API 設計，在以前程式碼優先方法是首選方法的情況下：
- 當需要快速交付程式碼時。
- 用於建立內部 API。
與設計優先的方法一樣，API 契約測試支援開發人員體驗、分散式團隊，並為拼圖中缺少的部分進行填補，使開發團隊能夠加快交付關鍵任務 API，支援內部和外部案例。
契約測試（Contract Testing）簡介以及為什麼需要它
契約測試回答了「我的 API 行為是否符合我們同意的方式？」這個問題。它平息了複雜的、可擴展的微服務架構造成的混亂。導入契約測試的團隊可以獲得以下好處：
- 可以針對每個單一整合點單獨進行測試
- 無需建立和管理專用的測試環境
- 在開發人員設備上直接提供快速可靠的回饋
- 一個簡單的 API 測試流程，可隨著業務和微服務的成長而線性擴展
- 允許團隊獨立部署他們的服務
契約測試為軟體開發團隊中的每個人提供了一定程度的品質所有權。因為我們透過更具體、有針對性的測試，更早地獲得了信心，所以我們可以將端到端測試重點放在它們的優勢上－完整的應用程式級功能－而不是選擇兩個單獨的API 是否可以相互溝通。這加快了發布週期並減少了管理依賴項、環境和資料所需的工作量。 正如您所看到的，契約測試是消除我們在微服務架構中可能感受到的一些痛苦的解藥。 觀看網路研討會：設計第一世界的 API 契約測試
在您的團隊中實施契約測試
我們慢慢地看到市場上出現契約測試工具或為既有工具提供了完成契約測試的方法。在過去的十年中，Pact 規範已成為事實上的標準，並且是契約測試中採用最廣泛、最值得信賴的規範。Pact 支援 10 多種語言，並且正在擴展其多協定功能。許多人選擇了 Pact 和自架的 Pact Broker（儲存契約的地方）。 對於喜歡外部託管版本的團隊來說，替代方案是 PactFlow。作為大規模交付契約測試的完整解決方案，PactFlow 圍繞著 Pact 框架建立，並具有安全性、用戶管理和專有的雙向契約測試框架等附加優勢。
如何協調 API 設計優先的契約測試
現在把它們拼湊起來，設定設計優先的契約測試方法需要 PactFlow 和 SwaggerHub 帳戶。有了這些，您可以按照幾個步驟操作，然後就可以開始執行了。
1. 編寫OpenAPI定義文件
這將成為我們用來啟動整個工作流程的事實來源—最好的地方是在 SwaggerHub 內。
2. 將使用者的可見性帶入設計階段
使用 PactFlow 的資料，現在可以在設計階段讓使用者可見，以幫助我們了解如何以不會影響客戶的方式更改設計，並防止在設計階段發生重大更改。如果需要，我們可以持續更新設計，讓其他利害關係人參與、簽署，並發布新版本。一旦我們發布了這個設計，我們現在就開放了開發和測試以及其他流程、文件等的能力。從這個過程開始。這一切都可以同時發生。
3. 在開發過程中確認 OpenAPI 規格 (OAS)
因此，在開發過程中，我們可以使用 OpenAPI 檔案產生程式碼，用於快速建立整合點的使用者端或整合點的提供者端。這就是我們引入契約測試以獲得額外覆蓋範圍的地方－API 設計者和開發者將了解我們的使用者如何使用 API 並驗證 API，確保它不會與使用者不同步，更不會與我們正在使用的實際 OpenAPI 文件不同步。這就是防止開發過程中出現偏差的最好方法。
4. 提供者契約的功能測試
稍後在 SDLC 的測試階段，我們可以圍繞 OpenAPI 定義建立測試方法。這樣做的一種方法是使用功能測試工具，例如 ReadyAPI 或其他開源工具（如 Dredd），透過讀取或匯入 OpenAPI 文件，然後向您的提供者發出 Request ，以確保其合規性。所有內建 Assertion 將會確保它與 OpenAPI 定義相容。
5. 使用「can-i-deploy」控制發布
一旦我們完成了開發和測試，就該發布了。團隊可以利用 PactFlow 內部的功能，在這裡我們可以獲得使用者契約的所有可見性—使用者對 API 提供者的需求以及 API 提供者可以做些什麼，也就是整個生態系統整合的可見性。然後我們會使用 PactFlow 的 can-i-deploy 功能問「發布這些更新安全嗎？」。這並不意外—因為 OpenAPI 定義已經來到這裡，我們知道它來自與實際設計和程式開發直接相關的真實來源。我們知道它始終是最新的，並且是正確的。因此我們可以知道文件將會發布並且這個更新這是值得信賴的。
這一切都是透過 PactFlow 獨有的雙向契約測試功能而予以實現。
為什麼現在需要這種方法？
如果您的團隊經歷了混亂的微服務蔓延的症狀—部署時間過長、Production 中一堆的錯誤、分散式團隊，那們您真的值得花一點時間了解設計優先的契約測試方法。使用 SwaggerHub 和 PactFlow 將提高設計優先的 API 開發工作流程品質，並有助於應對微服務部署的複雜性。以下是您可以期待的結果：
- SwaggerHub 可用於統整團隊使用單一事實來源管理與設計 OpenAPI 規範。
- 穩定、高效率、有系統的 API 開發流程可重複執行的基礎。
- PactFlow 提高了使用者如何使用您的 API 的可見性。
- 開發團隊可以獨立、安全地工作，以加快發布週期。
- 透過重複使用整合點兩側的現有測試，快速增加整個系統的測試覆蓋範圍，預防重大變更可能帶來的破壞。
- 減少 API 版本控制的需求。
- 使用 PactFlow 的雙向契約測試功能，團隊可以對已經存在這些工具和流程的現有系統進行改造。
- 提高契約測試計劃的投資報酬率。
透過 PactFlow 和 SwaggerHub 整合免費嘗試設計優先的 API 契約測試，可至原廠官網 了解更多 或 和我們聯絡。