消費者主導の契約テストのガイド

在現代微服務架構中，應用程式嚴重依賴服務間通訊（通常透過 API）。確保這些 API 在開發期間和更改後繼續按預期工作至關重要。實現這一目標的一種有效方法是透過消費者驅動的契約測試（CDCT）。 CDCT 是一種確保服務（生產者）遵守使用其 API 的服務（消費者）設定的期望的方法。

在本指南中，我們將探討 CDCT 是什麼、它是如何運作的、它在確保可靠的微服務互動方面的重要性，以及如何使用 Pact 等工具來實現它。

什麼是消費者驅動的契約測試？
消費者驅動的合約測試是一種測試策略，可確保分散式架構中的服務之間的通訊遵守商定的合約。它與傳統的 API 測試不同，它專注於消費者的需求，而不僅僅是確保 API 本身正常運作。 API 消費者和提供者之間的契約是由消費者的期望定義的，並且該契約根據提供者的實作進行驗證。

關鍵術語：
• Consumer：使用API​​ 的服務。
• Provider（生產者）：提供API的服務。
• 合約：消費者和提供者之間的正式協議，指定預期的 API 行為。

它是如何運作的？

1. 消費者定義合約： 消費者定義其對提供者 API 應如何表現的期望（例如，其期望的端點、資料格式和回應狀態代碼）。
2. 合約是共享的： 消費者與提供者分享此合約。該合約作為提供者必須滿足的規範。
3. 提供者驗證合約： 提供者根據消費者的合約進行自我測試，確保其滿足消費者的期望。
4. 持續回饋循環： 對提供者 API 的任何重大變更都將儘早發現，因為提供者必須根據所有消費者的合約進行驗證。這創建了一個安全網，以確保提供者的變化不會對消費者產生負面影響。

消費者驅動的合約測試的重要性
在分散式架構中，尤其是微服務，管理服務之間的依賴關係變得更加複雜。 CDCT 透過多種方式幫助減輕這種複雜性：

1。防止生產中的破損
由於消費者定義了他們的需求，因此供應商 API 的變更如果不滿足消費者的期望，就會在開發流程的早期被捕獲。這降低了由於不相容的更改而破壞生產系統的風險。

2。解耦開發
消費者驅動的契約測試允許消費者和提供者獨立開發。當團隊或服務單獨發展時，這尤其有用。合約充當接口，確保整合按預期工作，無需在每個開發週期進行完整的整合測試。

3。更快的開發週期
透過 CDCT，消費者和提供者都可以並行開發和測試，從而加快開發速度。即使在消費者完全實現其功能之前，提供者也可以針對消費者的合約進行測試。

4。及早發現合約違規行為
在開發過程的早期檢測到違反合約的提供者更改，使開發人員能夠在問題變得嚴重之前解決問題。

如何實施消費者驅動的合約測試
有多種工具可用於實施 CDCT，其中 Pact 是最受歡迎的工具之一。 Pact 允許消費者定義他們的合約並讓提供者驗證它們。

這是使用 Pact 實作 CDCT 的逐步指南：
第 1 步： 定義消費者期望
首先，在消費者服務中，定義契約。這通常包括以下內容：
• 消費者將呼叫的端點。
• 請求方法（GET、POST、PUT 等）。
• 預期的請求內文或參數。
• 預期的回應正文和狀態代碼。
以下是在 JavaScript 中使用 Pact 在消費者測試中定義合約的範例：

const { Pact } = require('@pact-foundation/pact');
const path = require('path');

const provider = new Pact({
    consumer: 'UserService',
    provider: 'UserAPI',
    port: 1234,
    log: path.resolve(process.cwd(), 'logs', 'pact.log'),
    dir: path.resolve(process.cwd(), 'pacts'),
});

describe('Pact Consumer Test', () => {
    beforeAll(() => provider.setup());

    afterAll(() => provider.finalize());

    it('should receive user details from the API', async () => {
        // Define the expected interaction
        await provider.addInteraction({
            state: 'user exists',
            uponReceiving: 'a request for user details',
            withRequest: {
                method: 'GET',
                path: '/users/1',
                headers: {
                    Accept: 'application/json',
                },
            },
            willRespondWith: {
                status: 200,
                headers: {
                    'Content-Type': 'application/json',
                },
                body: {
                    id: 1,
                    name: 'John Doe',
                },
            },
        });

        // Make the actual request and test
        const response = await getUserDetails(1);
        expect(response).toEqual({ id: 1, name: 'John Doe' });
    });
});

在此範例中，消費者 (UserService) 希望提供者 (UserAPI) 在向 /users/1 發出 GET 請求時傳回使用者詳細資料。

Step 2: Publish the Contract
Once the consumer test passes, Pact generates a contract file (Pact file) that can be shared with the provider. This contract can be stored in a Pact broker or a version control system so that the provider can use it for verification.

Step 3: Provider Verifies the Contract
The provider retrieves the contract and verifies that it complies with the consumer’s expectations. This is done by running a Pact test on the provider's side. Here’s an example of verifying a Pact contract in Java:

public class ProviderTest {

    @Test
    public void testProviderAgainstPact() {
        PactVerificationResult result = new PactVerifier()
            .verifyProvider("UserAPI", "pacts/UserService-UserAPI.json");

        assertThat(result, instanceOf(PactVerificationResult.Ok.class));
    }
}

The provider runs this test to ensure that it adheres to the contract specified by the consumer.

Step 4: Continuous Integration
Once CDCT is integrated into your CI/CD pipeline, each time a contract changes, the provider can automatically verify the contract. This ensures that API changes do not break the consumer’s expectations, providing a safety net for both teams.

CDCT Best Practices

1. Small, Focused Contracts: Ensure that your contracts are small and focus only on the consumer’s needs. This prevents unnecessary complexity in the contract and simplifies verification.
2. Contract Versioning: Always version your contracts. This allows providers to handle multiple versions of the same contract, helping you support different consumers at different stages of development.
3. Independent Deployment: Ensure that CDCT is part of your CI/CD pipeline. Any changes to the consumer or provider should trigger contract tests to avoid breaking production environments.
4. Use a Pact Broker: A Pact broker is a central repository that stores your contracts and allows both consumers and providers to retrieve them. It also provides a UI for visualizing contract versions and dependencies.

When to Use Consumer-Driven Contract Testing
CDCT is particularly useful when:
• You have microservices or distributed architectures with multiple services interacting.
• Teams working on different services need to develop independently without frequent integration testing.
• API contracts are likely to change often, and you want to avoid breaking consumer expectations.
• You need fast feedback loops to detect contract violations early in the development process.

Conclusion
Consumer-driven contract testing offers a reliable way to ensure that services in a distributed system communicate effectively without breaking changes. By focusing on consumer expectations and validating the provider against them, CDCT helps teams develop independently while ensuring stability. Whether you are building microservices, API-based applications, or distributed systems, incorporating CDCT into your testing strategy will improve the reliability and scalability of your services.

以上が消費者主導の契約テストのガイドの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。