Le WordPress d'aujourd'hui, décodé pour les développeurs

Tests

Tester la recherche Algolia synchronisée sans payer l’indexation en CI

Chaque exécution de la suite de tests ne doit pas réindexer un vrai compte Algolia. Voici comment simuler l'index sans jamais interroger le vrai service.

Par WordPress Développement • 11 octobre 2022 • 4 min de lecture • Aucun commentaire
Tester la recherche Algolia synchronisée sans payer l'indexation en CI

Combien coûte une indexation Algolia déclenchée à chaque exécution de la suite de tests, multipliée par une dizaine de développeurs qui poussent du code plusieurs fois par jour ? La question s’est posée concrètement chez un client e-commerce qui avait vu sa facture Algolia grimper anormalement un mois, sans nouveau trafic visiteur pour l’expliquer. La cause : la CI réindexait le catalogue complet à chaque merge de branche.

Le connecteur synchronisait chaque modification de produit WooCommerce vers un index Algolia via le hook save_post_product. En test, ce hook se déclenchait normalement, ce qui envoyait de vraies requêtes d’indexation vers de vrais index de test, consommant un quota facturé même en environnement de développement.

Isoler le client Algolia derrière une interface

La première étape, indépendante d’Algolia elle-même, consistait à ne jamais instancier directement \Algolia\AlgoliaSearch\SearchClient dans le code métier, mais à passer par une interface qu’on peut substituer en test.

interface IndexClientInterface
{
    public function sauvegarderObjet(string $index, array $objet): void;
    public function supprimerObjet(string $index, string $id): void;
}

final class AlgoliaIndexClient implements IndexClientInterface
{
    public function __construct(private SearchClient $client) {}

    public function sauvegarderObjet(string $index, array $objet): void
    {
        $this->client->initIndex($index)->saveObject($objet);
    }

    public function supprimerObjet(string $index, string $id): void
    {
        $this->client->initIndex($index)->deleteObject($id);
    }
}

Écrire un faux client entièrement en mémoire

Pour la CI, un faux client stocke simplement les objets dans un tableau, ce qui permet de vérifier le contenu exact envoyé à Algolia sans jamais quitter le processus PHP.

L'essentiel à retenir : Interroger le vrai Algolia à chaque build coûte des requêtes facturées inutilement ; Un faux client Algolia en mémoire suffit à couvrir la logique de synchronisation ; Réserver un seul test d'intégration réel, hors CI, pour valider la connexion effective
final class FauxIndexClient implements IndexClientInterface
{
    /** @var array<string, array<string, array>> */
    public array $index = [];

    public function sauvegarderObjet(string $index, array $objet): void
    {
        $this->index[$index][$objet['objectID']] = $objet;
    }

    public function supprimerObjet(string $index, string $id): void
    {
        unset($this->index[$index][$id]);
    }
}

class SynchronisationProduitTest extends WP_UnitTestCase
{
    public function test_la_mise_a_jour_dun_produit_synchronise_le_prix(): void
    {
        $faux_client = new FauxIndexClient();
        $service = new SynchronisationAlgolia($faux_client);

        $produit_id = self::factory()->post->create(['post_type' => 'product']);
        update_post_meta($produit_id, '_price', '29.90');

        $service->synchroniser($produit_id);

        $this->assertSame(
            '29.90',
            $faux_client->index['produits'][(string) $produit_id]['price']
        );
    }
}

Couvrir la suppression et le filtrage des produits privés

Le faux client permet aussi de vérifier des règles métier qui seraient coûteuses et lentes à valider contre un vrai index : un produit dépublié doit être retiré de l’index, pas simplement laissé avec un statut incohérent.

  • Un produit passant en brouillon déclenche supprimerObjet, jamais sauvegarderObjet.
  • Un produit en rupture de stock reste indexé mais avec un attribut en_stock: false, filtrable côté front.
  • Un produit variable synchronise chaque variation comme un objet distinct, avec un objectID composé de l’identifiant parent et de la variation.

Réserver un seul vrai test d’intégration, hors CI

Le faux client couvre toute la logique métier, mais ne garantit jamais que le format de données envoyé est réellement accepté par l’API Algolia actuelle. Un unique test d’intégration, exécuté manuellement ou sur un cron nocturne séparé de la CI principale, interroge un vrai index de recette pour vérifier que le contrat de format n’a pas changé côté service.

Le faux client ne remplace pas Algolia : il remplace uniquement le besoin de l’interroger cent fois par jour pour tester une logique qui, elle, ne dépend pas du réseau.

En résumé

Isoler le client Algolia derrière une interface, remplacée par un double en mémoire dans la CI, élimine à la fois la facturation inutile et la lenteur réseau, sans sacrifier la couverture des règles métier de synchronisation. Un seul test d’intégration réel, exécuté hors du flux principal, suffit à garder confiance dans la compatibilité avec le vrai service.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi