# Simuler une panne HubSpot dans une suite de tests d’extension WordPress

> Que fait votre connecteur CRM quand HubSpot répond 503 ? La réponse ne doit jamais être « on ne sait pas », et un test peut le garantir.

- Auteur : WordPress Développement
- Publié le : 2021-11-29
- Mis à jour le : 2021-11-29
- Catégorie : Tests
- URL : https://www.wpmoderne.fr/tests/simuler-panne-hubspot-tests-extension/

## L’essentiel

- Une panne d'API distante doit dégrader proprement, pas planter
- Une file d'attente locale absorbe l'indisponibilité temporaire
- Le message affiché à l'utilisateur doit rester clair, jamais une trace technique brute

`wp_remote_post()` qui retourne un `WP_Error`, ou pire, une réponse HTTP 503 avec un corps HTML de page de maintenance HubSpot : c'est le scénario qu'un connecteur d'extension doit absolument prévoir, et que la majorité des suites de tests ignorent purement et simplement.

Le connecteur en question synchronisait les inscriptions d'un formulaire de contact vers une liste HubSpot, à chaque soumission. Tant que l'API répondait, tout fonctionnait. Le jour où HubSpot a connu une panne partielle de quelques minutes, chaque soumission de formulaire s'est traduite par une erreur 500 côté site, visible par les visiteurs, alors que le seul problème venait d'un service tiers totalement indépendant du site lui-même.

## Simuler la panne sans dépendre du vrai service

Le principe reste le même que pour tout appel API externe testé en local : intercepter la requête sortante via le filtre `pre_http_request` et renvoyer une réponse fabriquée qui imite la panne, sans jamais toucher au réseau.

```
add_filter('pre_http_request', function ($preempt, $args, $url) {
    if (str_contains($url, 'api.hubapi.com')) {
        return new WP_Error(
            'http_request_failed',
            'Connexion à HubSpot impossible (simulation de test).'
        );
    }
    return $preempt;
}, 10, 3);
```

## Vérifier la dégradation, pas seulement l'absence de crash

Un test qui se contente de vérifier que le code ne lève pas d'exception est insuffisant : il faut vérifier ce que fait réellement le connecteur en cas d'échec.

> L'essentiel à retenir : Une panne d'API distante doit dégrader proprement, pas planter ; Une file d'attente locale absorbe l'indisponibilité temporaire ; Le message affiché à l'utilisateur doit rester clair, jamais une trace technique brute

```
class SynchronisationHubspotTest extends WP_UnitTestCase
{
    public function test_une_panne_hubspot_met_la_soumission_en_file_dattente(): void
    {
        $this->simuler_panne_hubspot();

        $connecteur = new HubspotConnecteur();
        $resultat = $connecteur->synchroniser([
            'email' => 'test@example.test',
            'prenom' => 'Camille',
        ]);

        $this->assertTrue($resultat->est_en_attente());
        $this->assertCount(1, get_option('hubspot_file_attente', []));
    }
}
```

Ce test-là garantit deux choses en une seule assertion réaliste : la soumission n'est pas perdue, et l'appelant (souvent un contrôleur de formulaire) reçoit une réponse qui ne ressemble pas à une erreur fatale.

### Le message affiché ne doit jamais exposer la panne technique

Autre point souvent oublié : que voit l'internaute qui remplit le formulaire pendant la panne ? Le test doit aussi couvrir le rendu du message de confirmation.

- Le formulaire doit afficher un message de succès générique, jamais le contenu brut du `WP_Error`.
- Un journal d'erreurs interne (via `error_log` ou un logger dédié) doit conserver la trace technique pour l'équipe support.
- Une tâche planifiée (`wp_schedule_event`) doit reprendre la file d'attente dès que l'API redevient disponible, sans double envoi.

## Couvrir le rejeu et la reprise après panne

Une fois la panne simulée et absorbée, il reste à vérifier la reprise : la file d'attente doit se vider proprement quand HubSpot répond à nouveau, sans dupliquer les contacts déjà synchronisés avant l'incident.

```
public function test_la_reprise_vide_la_file_sans_doublon(): void
{
    update_option('hubspot_file_attente', [
        ['email' => 'deja-en-attente@example.test'],
    ]);

    $this->simuler_hubspot_disponible();

    (new HubspotConnecteur())->traiter_file_attente();

    $this->assertEmpty(get_option('hubspot_file_attente', []));
}
```

> Un connecteur CRM n'est robuste que le jour où l'on a testé sa panne, pas son fonctionnement nominal : c'est dans l'échec que se joue la confiance du client final.

## En résumé

Simuler une panne HubSpot ne demande ni compte de test ni accès réseau : le filtre `pre_http_request` suffit à fabriquer n'importe quel scénario d'échec, du timeout au 503. Ce qui compte ensuite, c'est de vérifier trois choses précises — la mise en file d'attente, le message affiché à l'internaute, et la reprise sans doublon — plutôt que de se contenter d'un test qui prouve seulement l'absence de crash immédiat.