Séparer le domaine métier des hooks WordPress dans une grosse extension

Peut-on tester une règle de calcul de remise sans démarrer WordPress ? Pour beaucoup d’extensions, la réponse honnête est non, simplement parce que la logique de calcul se trouve mélangée, dans une seule fonction, avec les appels à get_option(), apply_filters() ou WC_Order. Impossible d’exécuter cette fonction sans charger l’ensemble du cœur WordPress, ce qui rend chaque test lent et fragile.

Cet article détaille une approche simple pour séparer ce qui relève du domaine métier pur de ce qui relève de l’intégration à WordPress, sans passer par les frameworks de test PHP eux-mêmes, qui restent un sujet distinct. L’objectif est purement architectural : rendre le calcul testable, indépendamment de l’outil de test choisi ensuite.

À quoi ressemble le mélange classique

Voici une fonction typique, accrochée à un hook WooCommerce, qui calcule une remise fidélité et applique directement le résultat à la commande :

add_action( 'woocommerce_cart_calculate_fees', 'appliquer_remise_fidelite' );

function appliquer_remise_fidelite( $cart ) {
    $client_id = get_current_user_id();
    $points    = (int) get_user_meta( $client_id, 'points_fidelite', true );

    if ( $points >= 100 ) {
        $remise = min( 20, floor( $points / 100 ) * 2 );
        $cart->add_fee( 'Remise fidélité', -1 * $remise );
    }
}

Cette fonction fait deux choses à la fois : elle calcule une règle métier (le taux de remise en fonction des points) et elle l’applique concrètement à un panier WooCommerce. Pour tester uniquement la règle de calcul, il faudrait construire un objet WC_Cart complet, avec un utilisateur connecté et des métadonnées existantes, alors que la règle elle-même n’est qu’un calcul arithmétique simple.

Extraire le domaine métier dans une classe indépendante

La première étape consiste à isoler le calcul dans une classe qui ne connaît rien de WordPress, ni de WooCommerce : elle reçoit des valeurs simples en entrée, et retourne une valeur simple en sortie.

class Calculateur_Remise_Fidelite {

    public function calculer( int $points ) : float {
        if ( $points < 100 ) {
            return 0.0;
        }

        return min( 20.0, floor( $points / 100 ) * 2.0 );
    }
}

Cette classe peut être testée en quelques lignes, sans jamais charger WordPress :

$calculateur = new Calculateur_Remise_Fidelite();

assert( 0.0 === $calculateur->calculer( 50 ) );
assert( 2.0 === $calculateur->calculer( 100 ) );
assert( 20.0 === $calculateur->calculer( 5000 ) ); // plafond respecté

Réintégrer la classe dans le hook WordPress

La fonction accrochée au hook devient alors une simple couche de traduction : elle récupère les données WordPress nécessaires, les transmet au calculateur, puis applique le résultat retourné.

add_action( 'woocommerce_cart_calculate_fees', 'appliquer_remise_fidelite' );

function appliquer_remise_fidelite( $cart ) {
    $client_id = get_current_user_id();
    $points    = (int) get_user_meta( $client_id, 'points_fidelite', true );

    $calculateur = new Calculateur_Remise_Fidelite();
    $remise      = $calculateur->calculer( $points );

    if ( $remise > 0 ) {
        $cart->add_fee( 'Remise fidélité', -1 * $remise );
    }
}

Le comportement final reste strictement identique pour l’utilisateur du site. Ce qui change, c’est la possibilité de vérifier la règle de calcul indépendamment de tout le reste, et de faire évoluer cette règle sans craindre de casser l’intégration avec WooCommerce, puisque les deux responsabilités sont désormais séparées.

Où tracer la frontière

La question qui revient souvent : jusqu’où pousser cette séparation ? Une règle empirique simple aide à trancher : si une fonction contient un appel à une fonction WordPress ou WooCommerce (get_option(), get_user_meta(), $cart->add_fee()) mélangé à un calcul conditionnel non trivial, c’est le signe qu’il faut extraire le calcul. Si la fonction ne fait que transmettre une valeur ou déclencher un affichage simple, la séparer n’apporte généralement rien.

• Extraire toute règle de calcul comportant plusieurs conditions ou un arrondi métier significatif.
• Laisser dans la fonction de hook tout ce qui relève strictement de la lecture ou de l’écriture de données WordPress.
• Nommer les classes de domaine métier sans référence à WordPress, pour rappeler visuellement leur indépendance.

Une règle de calcul qui ne peut être testée qu’en démarrant WordPress entier n’est pas une règle de calcul isolée ; c’est un signe que le domaine métier et l’intégration sont encore mélangés.

En résumé

Cette séparation ne demande ni framework ni outillage particulier : une classe simple, sans dépendance externe, suffit à rendre une règle métier testable indépendamment du cœur WordPress. Le choix du framework de test à utiliser ensuite pour exécuter ces vérifications reste, volontairement, un sujet à part.