Une boutique qui vend des abonnements avec livraison récurrente nous a contactés après un incident classique : une mise à jour de thème avait discrètement cassé le bouton de validation de commande pour un seul mode de livraison sur trois, celui utilisé par près de 40 % des clients. Personne ne l’avait remarqué en recette manuelle, parce que les testeurs internes utilisaient systématiquement le mode de livraison par défaut. Le tunnel de commande complet mérite une suite E2E dédiée, précisément parce que c’est l’endroit où une régression coûte directement du chiffre d’affaires.
Cet article part du principe que vous savez déjà écrire un scénario Playwright basique : navigation, sélecteurs, assertions. On se concentre ici sur ce qui est spécifique à WooCommerce et à la fiabilité d’un tunnel de commande complet.
Préparer les données sans passer par l’interface
La tentation, en E2E, est de tout faire au clic : créer le produit, définir son stock, configurer la zone de livraison, depuis l’interface d’administration. C’est lent, fragile et ça mélange deux choses différentes : la configuration de la boutique et le comportement du tunnel de commande lui-même. On sépare les deux en créant les produits et les zones de livraison nécessaires via l’API REST WooCommerce, avant même de lancer le navigateur :
async function creerProduitDeTest(context, prefixe) {
const reponse = await context.request.post('/wp-json/wc/v3/products', {
data: {
name: `${prefixe} - Coffret dégustation`,
type: 'simple',
regular_price: '39.00',
manage_stock: true,
stock_quantity: 10,
},
});
const produit = await reponse.json();
return produit.id;
}Le préfixe unique par exécution, déjà recommandé pour n’importe quelle suite E2E, évite les collisions entre exécutions concurrentes de la CI et facilite le nettoyage après coup via un simple filtre sur ce préfixe.
Couvrir chaque mode de livraison séparément
C’est le point que l’incident cité en introduction a rendu prioritaire : chaque méthode de livraison active (retrait en magasin, livraison standard, livraison express) doit avoir son propre scénario, parce que chacune peut afficher des champs différents dans le formulaire de commande, ou déclencher des calculs de frais différents. On ne teste pas « le tunnel de commande » comme un bloc unique, mais autant de scénarios que de combinaisons réellement proposées aux clients.
Isoler le paiement avec une passerelle de test
WooCommerce fournit nativement la passerelle « Chèque » (cheque) et « Virement bancaire » (bacs), toutes deux utilisables sans aucune configuration externe et parfaitement adaptées aux tests E2E puisqu’elles ne déclenchent aucun appel réseau vers un prestataire tiers. Pour les projets qui utilisent Stripe ou PayPal en production, la bonne pratique consiste à activer leur mode bac à sable dans un environnement de test dédié, avec les cartes de test documentées par le prestataire, plutôt que de désactiver purement et simplement la passerelle réelle dans les tests.
test('commande avec virement bancaire aboutit', async ({ page, request }) => {
const produitId = await creerProduitDeTest(request, prefixe);
await page.goto(`/?add-to-cart=${produitId}`);
await page.goto('/panier/');
await page.click('text=Passer la commande');
await page.fill('#billing_first_name', 'Camille');
await page.fill('#billing_last_name', 'Reynaud');
await page.fill('#billing_email', `${prefixe}@example.test`);
await page.fill('#billing_address_1', '12 rue des Tilleuls');
await page.fill('#billing_postcode', '69003');
await page.fill('#billing_city', 'Lyon');
await page.check('#payment_method_bacs');
await page.click('#place_order');
await expect(page.locator('.woocommerce-order-received')).toBeVisible();
});Vérifier la commande côté back, pas seulement l’écran de confirmation
Un tunnel de commande qui affiche la page de remerciement peut malgré tout avoir échoué à créer la commande correctement en base : montant mal calculé, statut resté en attente au lieu de passer en traitement, ligne de produit dupliquée. Le scénario doit donc interroger l’API REST après la soumission pour valider l’état réel de la commande créée, en plus de l’assertion visuelle sur la page :
- Récupérer l’identifiant de commande depuis l’URL de la page de confirmation
- Interroger
GET /wp-json/wc/v3/orders/{id}avec des identifiants d’API dédiés au test - Vérifier le statut, le total, et le nombre de lignes de produits attendues
Stabilité : le panier AJAX est le point le plus fragile
WooCommerce met à jour le mini-panier et le total de commande via des appels AJAX qui prennent un temps variable selon le nombre de plugins actifs sur le hook woocommerce_cart_updated. Attendre systématiquement la disparition d’un indicateur de chargement (classe .blockUI ou équivalent selon le thème) avant toute assertion sur le contenu du panier évite la grande majorité des faux échecs constatés sur ce type de scénario.
Sur un tunnel de commande, un test qui « passe presque toujours » n’est pas acceptable : c’est l’endroit précis où chaque échec réel se traduit par une vente perdue.
Nettoyage systématique après chaque exécution
Les commandes, produits et coupons créés pour les tests doivent être supprimés à la fin de la suite, via l’API REST avec le paramètre force=true pour éviter de les laisser dans la corbeille. Un job de nettoyage périodique, indépendant de la CI elle-même, filtre en complément tout ce qui porterait un préfixe de test oublié après un échec de build.
En résumé
Un tunnel de commande WooCommerce bien couvert en E2E ne teste pas « une commande », mais la combinaison réelle des modes de livraison et de paiement proposés aux clients, avec une vérification qui descend jusqu’à l’état de la commande en base, pas seulement jusqu’à l’écran de confirmation. C’est un investissement qui se justifie dès qu’une boutique génère un chiffre d’affaires suffisant pour qu’une régression silencieuse de quelques jours coûte plus cher que la suite de tests elle-même.
