# Tester un connecteur Brevo sans déclencher de vrais envois

> Comment valider la logique de segmentation d'un connecteur Brevo sans polluer une vraie liste de contacts ni déclencher un envoi réel pendant les tests.

- Auteur : Clément Hadrot
- Publié le : 2025-01-30
- Mis à jour le : 2025-01-30
- Catégorie : Tests
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/tester-connecteur-brevo-sans-envois-reels/

## L’essentiel

- Ne jamais pointer les tests vers le compte Brevo de production
- Intercepter les appels HTTP sortants plutôt que d'utiliser un compte bac à sable
- Vérifier la segmentation, pas la delivrabilité de Brevo elle-même

`curl -X POST https://api.brevo.com/v3/contacts` — cette requête, exécutée par erreur pendant une exécution de test avant la mise en place d'une interception propre, a créé onze faux contacts dans la liste de production d'un client, avec des adresses e-mail générées automatiquement du type `test-3f8a@example.com`. Rien de grave en soi, mais suffisant pour fausser les statistiques de segmentation pendant plusieurs jours avant d'être repéré et nettoyé manuellement.

Ce billet documente la méthode que nous avons mise en place pour tester la logique de segmentation d'un connecteur Brevo sans jamais toucher un vrai compte, ni réel ni bac à sable. Il ne traite pas de Mailjet, utilisé sur un autre projet pour un usage transactionnel distinct (confirmations de commande), avec des contraintes de test différentes.

## Pourquoi éviter même un compte Brevo de test dédié

Un compte Brevo « bac à sable » reste un service externe réel : latence réseau variable, quotas d'API, disponibilité non garantie pendant l'exécution de la CI. Dépendre de ce compte pour faire tourner une suite de tests introduit une fragilité externe au projet — un test qui échoue parce que Brevo est temporairement indisponible n'apprend rien sur la qualité du code testé.

Notre approche consiste à intercepter les appels HTTP sortants du connecteur avant qu'ils n'atteignent le réseau, via le filtre `pre_http_request` de WordPress, qui permet de court-circuiter `wp_remote_post()` et de renvoyer une réponse simulée.

## Intercepter l'appel avec pre_http_request

```
add_filter('pre_http_request', function ($preempt, $args, $url) {
    if (strpos($url, 'api.brevo.com/v3/contacts') === false) {
        return $preempt;
    }

    return [
        'response' => ['code' => 201, 'message' => 'Created'],
        'body' => wp_json_encode(['id' => 42, 'email' => $args['body']['email'] ?? '']),
    ];
}, 10, 3);
```

Cette interception permet de tester la logique de segmentation — quel contact va dans quelle liste, selon quels attributs — sans qu'aucun appel réseau ne quitte jamais l'environnement de test.

> L'essentiel à retenir : Ne jamais pointer les tests vers le compte Brevo de production ; Intercepter les appels HTTP sortants plutôt que d'utiliser un compte bac à sable ; Vérifier la segmentation, pas la delivrabilité de Brevo elle-même

## Ce que ces tests couvrent réellement

- Un contact avec un attribut personnalisé `DATE_ADHESION` récente est bien affecté à la liste « nouveaux adhérents »
- Un contact qui change de statut de don passe correctement de la liste « prospects » à la liste « donateurs actifs », sans rester dans les deux
- Un contact désinscrit (statut `unsubscribed` renvoyé par Brevo) n'est jamais réinscrit automatiquement par une synchronisation ultérieure
- Un attribut manquant dans la charge envoyée par l'application ne fait pas planter l'appel, mais génère un contact avec l'attribut par défaut attendu

### Vérifier aussi les erreurs renvoyées par Brevo

L'interception permet également de simuler les erreurs réelles de l'API Brevo, notamment un code 400 pour un e-mail malformé ou un code 429 en cas de dépassement de quota, pour vérifier que le connecteur applique bien une nouvelle tentative avec un délai croissant plutôt que d'abandonner silencieusement l'envoi.

## Ce que ces tests ne couvrent pas

Cette suite ne vérifie jamais que Brevo délivre effectivement les e-mails, ni la qualité de sa délivrabilité — ce sont des aspects qui relèvent du service lui-même, pas du code du connecteur. Un contrôle manuel ponctuel sur un compte de test reste nécessaire, mais en dehors de la suite automatisée, et avec une fréquence bien plus faible.

> Tester un connecteur vers un service tiers, c'est tester ce que fait votre code avec la réponse du service, jamais le service lui-même.

## En résumé

Intercepter les appels HTTP sortants avec `pre_http_request` permet de tester exhaustivement la logique métier d'un connecteur Brevo sans risque pour les données réelles, à un coût de mise en place minime comparé au risque d'un compte pollué en production.