Dans les architectures de microservices modernes, les applications s'appuient fortement sur la communication interservices, souvent via des API. Il est essentiel de garantir que ces API continuent de fonctionner comme prévu pendant le développement et après les modifications. Un moyen efficace d’y parvenir consiste à recourir aux tests de contrats axés sur le consommateur (CDCT). CDCT est une méthode qui garantit que les services (producteurs) adhèrent aux attentes fixées par les services qui consomment leurs API (consommateurs).

Dans ce guide, nous explorerons ce qu'est le CDCT, comment il fonctionne, son importance pour garantir des interactions de microservices fiables et comment vous pouvez le mettre en œuvre à l'aide d'outils tels que Pact.

Qu'est-ce que les tests de contrats axés sur le consommateur ?
Les tests de contrats axés sur le consommateur sont une stratégie de test qui garantit que la communication entre les services dans une architecture distribuée respecte les contrats convenus. Il diffère des tests d'API traditionnels en se concentrant sur les besoins des consommateurs, plutôt que de simplement garantir le bon fonctionnement de l'API elle-même. Le contrat entre le consommateur et le fournisseur de l'API est défini par les attentes du consommateur, et ce contrat est vérifié par rapport à la mise en œuvre du fournisseur.

Termes clés :
• Consommateur : service qui consomme l'API.
• Fournisseur (Producteur) : service qui fournit l'API.
• Contrat : un accord formel entre le consommateur et le fournisseur qui spécifie le comportement attendu de l'API.

Comment ça marche ?

1. Le consommateur définit le contrat : Le consommateur définit ses attentes sur la façon dont l'API du fournisseur doit se comporter (par exemple, les points de terminaison, les formats de données et les codes d'état de réponse qu'il attend).
2. Le contrat est partagé : Le consommateur partage ce contrat avec le fournisseur. Ce contrat sert de spécification de ce que le fournisseur doit respecter.
3. Le fournisseur vérifie le contrat : Le fournisseur se teste par rapport au contrat du consommateur, s'assurant qu'il répond aux attentes du consommateur.
4. Boucle de rétroaction continue : Toute modification importante apportée à l'API du fournisseur sera détectée rapidement, car le fournisseur doit valider par rapport aux contrats de tous les consommateurs. Cela crée un filet de sécurité pour garantir que les changements chez le fournisseur n'affectent pas négativement les consommateurs.

Importance des tests de contrats axés sur le consommateur
Dans les architectures distribuées, notamment avec les microservices, la gestion des dépendances entre services devient plus complexe. CDCT contribue à atténuer cette complexité de plusieurs manières :

1. Empêche les ruptures de production
Étant donné que les consommateurs définissent ce dont ils ont besoin, les modifications apportées à l’API du fournisseur qui ne répondent pas à leurs attentes sont détectées dès le début du processus de développement. Cela réduit le risque de rupture des systèmes de production en raison de changements incompatibles.

2. Découplage du développement
Les tests de contrats axés sur le consommateur permettent aux consommateurs et aux fournisseurs de se développer de manière indépendante. Ceci est particulièrement utile lorsque les équipes ou les services évoluent séparément. Les contrats servent d'interface garantissant que l'intégration fonctionne comme prévu sans avoir besoin de tests d'intégration complets à chaque cycle de développement.

3. Cycles de développement plus rapides
Avec CDCT, le consommateur et le fournisseur peuvent être développés et testés en parallèle, accélérant ainsi le développement. Les fournisseurs peuvent tester le contrat du consommateur avant même que celui-ci ne mette pleinement en œuvre ses fonctionnalités.

4. Détection précoce des violations de contrat
Les modifications apportées au fournisseur qui violent le contrat sont détectées dès le début du processus de développement, ce qui permet aux développeurs de résoudre les problèmes avant qu'ils ne deviennent critiques.

Comment mettre en œuvre des tests de contrats axés sur le consommateur
Plusieurs outils sont disponibles pour mettre en œuvre le CDCT, Pact étant l'un des plus populaires. Pact permet aux consommateurs de définir leurs contrats et aux prestataires de les vérifier.

Voici un guide étape par étape pour mettre en œuvre le CDCT à l'aide de Pact :
Étape 1 : Définir les attentes des consommateurs
Tout d’abord, dans le service consommateur, définissez le contrat. Cela inclut généralement les éléments suivants :
• Le point de terminaison que le consommateur appellera.
• La méthode de requête (GET, POST, PUT, etc.).
• Le corps ou les paramètres de la requête attendus.
• Le corps de la réponse et le code d'état attendus.
Voici un exemple de définition d'un contrat dans un test consommateur à l'aide de Pact en 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' });
    });
});

Dans cet exemple, le consommateur (UserService) s'attend à ce que le fournisseur (UserAPI) renvoie les détails de l'utilisateur lorsqu'il envoie une requête GET à /users/1.

Étape 2 : Publier le contrat
Une fois le test consommateur réussi, Pact génère un fichier de contrat (fichier Pact) qui peut être partagé avec le fournisseur. Ce contrat peut être stocké dans un courtier Pact ou un système de contrôle de version afin que le fournisseur puisse l'utiliser à des fins de vérification.

Étape 3 : Le fournisseur vérifie le contrat
Le prestataire récupère le contrat et vérifie qu’il est conforme aux attentes du consommateur. Cela se fait en exécutant un test Pact du côté du fournisseur. Voici un exemple de vérification d'un contrat Pact en Java :

public class ProviderTest {

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

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

Le fournisseur effectue ce test pour s'assurer qu'il respecte le contrat spécifié par le consommateur.

Étape 4 : Intégration continue
Une fois CDCT intégré dans votre pipeline CI/CD, chaque fois qu'un contrat change, le fournisseur peut automatiquement vérifier le contrat. Cela garantit que les modifications de l'API ne brisent pas les attentes du consommateur, offrant ainsi un filet de sécurité aux deux équipes.

Meilleures pratiques CDCT

1. Petits contrats ciblés : Assurez-vous que vos contrats sont de petite taille et se concentrent uniquement sur les besoins du consommateur. Cela évite une complexité inutile dans le contrat et simplifie la vérification.
2. Gestion des versions des contrats : Versionnez toujours vos contrats. Cela permet aux fournisseurs de gérer plusieurs versions du même contrat, vous aidant ainsi à prendre en charge différents consommateurs à différents stades de développement.
3. Déploiement indépendant : Assurez-vous que CDCT fait partie de votre pipeline CI/CD. Toute modification apportée au consommateur ou au fournisseur doit déclencher des tests contractuels pour éviter de perturber les environnements de production.
4. Utilisez un courtier Pact : Un courtier Pact est un référentiel central qui stocke vos contrats et permet aux consommateurs et aux fournisseurs de les récupérer. Il fournit également une interface utilisateur pour visualiser les versions et les dépendances du contrat.

Quand utiliser les tests de contrats axés sur le consommateur
Le CDCT est particulièrement utile lorsque :
• Vous disposez de microservices ou d'architectures distribuées avec plusieurs services en interaction.
• Les équipes travaillant sur différents services doivent se développer de manière indépendante sans tests d'intégration fréquents.
• Les contrats d'API sont susceptibles de changer souvent et vous souhaitez éviter de dépasser les attentes des consommateurs.
• Vous avez besoin de boucles de rétroaction rapides pour détecter les violations de contrat dès le début du processus de développement.

Conclusion
Les tests de contrats axés sur le consommateur offrent un moyen fiable de garantir que les services d'un système distribué communiquent efficacement sans interrompre les modifications. En se concentrant sur les attentes des consommateurs et en validant le fournisseur par rapport à celles-ci, CDCT aide les équipes à se développer de manière indépendante tout en garantissant la stabilité. Que vous construisiez des microservices, des applications basées sur des API ou des systèmes distribués, l'intégration de CDCT dans votre stratégie de test améliorera la fiabilité et l'évolutivité de vos services.