Est-ce qu’une suite de tests verte garantit qu’elle teste encore ce qu’elle prétend tester ? Après l’activation du stockage haute performance des commandes de WooCommerce, la réponse a été clairement non : 12 tests sur 90 continuaient de passer, mais en vérifiant des données qui n’étaient plus celles réellement utilisées par WooCommerce en production.
HPOS, disponible depuis la mi-2022, déplace les commandes hors de la table wp_posts vers des tables dédiées, wp_wc_orders en tête. L’API publique, wc_get_orders() et les objets WC_Order, reste identique en apparence. C’est précisément ce qui rend le problème sournois : le code métier fonctionne sans modification, mais certains tests contournaient cette API pour interroger directement la base.
Repérer les assertions qui trichent avec le schéma
La recherche a porté sur toutes les requêtes SQL brutes dans les tests, via global $wpdb suivi d’un SELECT sur wp_posts avec post_type = 'shop_order'. Ce motif, autrefois un raccourci pratique pour vérifier rapidement qu’une commande existait, ne renvoyait plus aucune ligne une fois HPOS activé.
// Ancien test, silencieusement obsolète avec HPOS activé
global $wpdb;
$count = $wpdb->get_var(
"SELECT COUNT(*) FROM {$wpdb->posts} WHERE post_type = 'shop_order'"
);
$this->assertSame( 1, $count );
Ce test ne passait plus jamais avec HPOS actif — mais il ne figurait pas dans la suite exécutée par défaut, car le job de CI ciblait encore l’ancien mode de stockage. Le risque réel se situait dans la CI, pas dans le code applicatif.
Réécrire avec l’API officielle de compatibilité
WooCommerce fournit OrderUtil::custom_orders_table_usage_is_enabled() pour détecter le mode actif, et surtout des fonctions d’accès qui fonctionnent identiquement dans les deux modes. La correction a consisté à remplacer chaque requête directe par l’API prévue.
$orders = wc_get_orders( array(
'status' => 'processing',
'limit' => -1,
) );
$this->assertCount( 1, $orders );
Cette réécriture a un avantage supplémentaire : le même test s’exécute désormais correctement que HPOS soit activé ou non, ce qui a permis de garder une compatibilité ascendante pour les sites qui n’ont pas encore basculé.
Ajouter un test de double-écriture
WooCommerce propose un mode de synchronisation où les deux schémas restent à jour simultanément, utile pendant une migration progressive. Un test spécifique vérifie que la commande créée via l’API est bien lisible depuis les deux sources tant que ce mode reste actif.
- Activation du mode de synchronisation dans le bootstrap de test
- Création d’une commande via
wc_create_order() - Vérification de cohérence entre les deux tables sous-jacentes
Faire tourner la CI dans les deux modes
Plutôt que de choisir un camp, la matrice de CI exécute désormais la suite deux fois : une fois avec HPOS désactivé pour les sites encore en migration, une fois activé pour l’usage cible. Les 12 tests corrigés passent dans les deux configurations ; les 78 autres, qui utilisaient déjà l’API publique, n’ont nécessité aucun changement.
Un test vert ne prouve rien s’il vérifie une hypothèse sur le stockage plutôt qu’un comportement observable par le code applicatif.
Ce que ce chantier ne couvre pas
La migration des données existantes d’un site en production vers les nouvelles tables reste un sujet distinct, traité par les outils de migration fournis par WooCommerce lui-même et documentés séparément. Ce chantier ne concernait que la suite de tests du plugin, pas la bascule d’un site réel.
En résumé
L’audit des requêtes SQL directes dans une suite de tests hérité a révélé une dette invisible : des assertions qui ne testaient plus rien de pertinent. La correction, en s’appuyant sur l’API officielle plutôt que sur le schéma interne, a rendu la suite compatible avec les deux modes de stockage — et plus robuste face à la prochaine évolution interne de WooCommerce.
