Panduan untuk Ujian Kontrak Didorong Pengguna

Dalam seni bina perkhidmatan mikro moden, aplikasi sangat bergantung pada komunikasi antara perkhidmatan, selalunya melalui API. Memastikan API ini terus berfungsi seperti yang diharapkan semasa pembangunan dan selepas perubahan adalah kritikal. Satu cara yang berkesan untuk mencapai matlamat ini ialah melalui Ujian Kontrak Didorong Pengguna (CDCT). CDCT ialah kaedah yang memastikan perkhidmatan (pengeluar) mematuhi jangkaan yang ditetapkan oleh perkhidmatan yang menggunakan API (pengguna) mereka.

Dalam panduan ini, kami akan meneroka apakah CDCT, cara ia berfungsi, kepentingannya dalam memastikan interaksi perkhidmatan mikro yang boleh dipercayai dan cara anda boleh melaksanakannya menggunakan alatan seperti Pact.

Apakah itu Ujian Kontrak Didorong Pengguna?
Ujian Kontrak Didorong Pengguna ialah strategi ujian yang memastikan komunikasi antara perkhidmatan dalam seni bina yang diedarkan mematuhi kontrak yang dipersetujui. Ia berbeza daripada ujian API tradisional dengan memfokuskan pada keperluan pengguna, bukannya hanya memastikan API itu sendiri berfungsi dengan betul. Kontrak antara pengguna dan penyedia API ditentukan oleh jangkaan pengguna dan kontrak ini disahkan terhadap pelaksanaan penyedia.

Syarat Utama:
• Pengguna: Perkhidmatan yang menggunakan API.
• Pembekal (Pengeluar): Perkhidmatan yang menyediakan API.
• Kontrak: Perjanjian rasmi antara pengguna dan pembekal yang menyatakan gelagat API yang dijangkakan.

Bagaimana Ia Berfungsi?

1. Pengguna Mentakrifkan Kontrak: Pengguna mentakrifkan jangkaan mereka tentang cara API pembekal harus bertindak (mis., titik akhir, format data dan kod status respons yang dijangkakan).
2. Kontrak Dikongsi: Pengguna berkongsi kontrak ini dengan pembekal. Kontrak ini berfungsi sebagai spesifikasi untuk perkara yang mesti dipenuhi oleh pembekal.
3. Pembekal Mengesahkan Kontrak: Pembekal menguji dirinya terhadap kontrak pengguna, memastikan ia memenuhi jangkaan pengguna.
4. Gelung Maklum Balas Berterusan: Sebarang perubahan pecah pada API penyedia akan ditangkap lebih awal kerana penyedia mesti mengesahkan terhadap semua kontrak pengguna. Ini mewujudkan jaring keselamatan untuk memastikan perubahan dalam pembekal tidak memberi kesan negatif kepada pengguna.

Kepentingan Ujian Kontrak Didorong Pengguna
Dalam seni bina teragih, terutamanya dengan perkhidmatan mikro, mengurus kebergantungan antara perkhidmatan menjadi lebih kompleks. CDCT membantu mengurangkan kerumitan ini dalam beberapa cara:

1. Mengelakkan Pecah dalam Pengeluaran
Memandangkan pengguna mentakrifkan perkara yang mereka perlukan, perubahan kepada API penyedia yang tidak memenuhi jangkaan pengguna ditangkap lebih awal dalam perancangan pembangunan. Ini mengurangkan risiko memecahkan sistem pengeluaran akibat perubahan yang tidak serasi.

2. Pembangunan Penyahgandingan
Ujian kontrak yang didorong oleh pengguna membolehkan pengguna dan pembekal membangun secara bebas. Ini amat berguna apabila pasukan atau perkhidmatan berkembang secara berasingan. Kontrak berfungsi sebagai antara muka yang memastikan integrasi berfungsi seperti yang diharapkan tanpa memerlukan ujian integrasi penuh semasa setiap kitaran pembangunan.

3. Kitaran Pembangunan Lebih Pantas
Dengan CDCT, kedua-dua pengguna dan pembekal boleh dibangunkan dan diuji secara selari, mempercepatkan pembangunan. Penyedia boleh menguji terhadap kontrak pengguna walaupun sebelum pengguna melaksanakan sepenuhnya fungsinya.

4. Pengesanan Awal Pelanggaran Kontrak
Perubahan kepada pembekal yang melanggar kontrak dikesan awal dalam proses pembangunan, membolehkan pembangun menangani isu sebelum ia menjadi kritikal.

Cara Melaksanakan Ujian Kontrak Didorong Pengguna
Beberapa alat tersedia untuk melaksanakan CDCT, dengan Pact menjadi salah satu yang paling popular. Pakatan membenarkan pengguna mentakrifkan kontrak mereka dan pembekal untuk mengesahkannya.

Berikut ialah panduan langkah demi langkah untuk melaksanakan CDCT menggunakan Pact:
Langkah 1: Tentukan Jangkaan Pengguna
Pertama, dalam perkhidmatan pengguna, tentukan kontrak. Ini biasanya termasuk yang berikut:
• Titik akhir yang akan dipanggil oleh pengguna.
• Kaedah permintaan (GET, POST, PUT, dll.).
• Badan atau parameter permintaan yang dijangkakan.
• Badan respons yang dijangkakan dan kod status.
Berikut ialah contoh mentakrifkan kontrak dalam ujian pengguna menggunakan Pact dalam JavaScript:

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

Dalam contoh ini, pengguna (UserService) mengharapkan pembekal (UserAPI) untuk mengembalikan butiran pengguna apabila membuat permintaan GET kepada /users/1.

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.

Atas ialah kandungan terperinci Panduan untuk Ujian Kontrak Didorong Pengguna. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!