62 % des tests de cette extension portent sur des règles qu’aucun autre projet e-commerce du portefeuille de l’agence n’a jamais eu à vérifier : validité d’une ordonnance, traçabilité de lot pour un dispositif médical, restriction de vente selon la réglementation en vigueur. La pyramide de tests générique qu’on applique habituellement aux projets WooCommerce d’agence ne collait tout simplement pas à ce périmètre.
Le module vendait des dispositifs médicaux de classe I nécessitant, pour certaines références, le téléversement d’une ordonnance validée par un pharmacien avant expédition. Contrairement à un site e-commerce classique où la majorité de la complexité se situe dans le tunnel de paiement, ici la complexité se situait en amont : validation documentaire, traçabilité de lot, et restrictions de vente par zone géographique liées à la réglementation des dispositifs médicaux.
Pourquoi la pyramide générique ne suffisait pas
La pyramide de tests qu’on utilise pour un projet e-commerce d’agence classique répartit grossièrement l’effort à 60 % unitaire, 30 % intégration, 10 % bout en bout, en misant sur le fait que la logique métier reste relativement simple et bien isolable. Ici, deux facteurs changeaient la donne :
- La validation d’ordonnance dépendait d’un service externe de vérification pharmaceutique, ce qui déplaçait naturellement une partie de la couverture vers l’intégration plutôt que l’unitaire pur.
- La traçabilité de lot devait rester cohérente à travers tout le cycle de vie de la commande (achat, expédition, éventuel rappel de lot), un scénario qui ne se prête pas à un test unitaire isolé.
Notre répartition retenue : 45/35/20
Pyramide retenue pour ce projet
├── Unitaire (45 %)
│ ├── Règles de validité d'une ordonnance (dates, signature, référence produit)
│ ├── Calcul de la quantité maximale autorisée par ordonnance
│ └── Règles de restriction de vente par zone géographique
├── Intégration (35 %)
│ ├── Appel au service de vérification pharmaceutique (simulé)
│ ├── Traçabilité de lot à travers commande → expédition → éventuel rappel
│ └── Synchronisation des stocks par lot avec l'ERP du fournisseur
└── Bout en bout (20 %)
├── Parcours d'achat complet avec téléversement d'ordonnance
└── Parcours de rappel de lot déclenché depuis l'administration
Ce que la couche unitaire couvre en détail
La validation d’ordonnance concentre à elle seule une trentaine de tests unitaires, car les règles combinent plusieurs conditions indépendantes : date de validité de l’ordonnance (généralement un an), correspondance entre la référence produit commandée et celle prescrite, quantité maximale autorisée sur une même ordonnance.
class ValiditeOrdonnanceTest extends TestCase
{
public function test_une_ordonnance_de_plus_dun_an_est_refusee(): void
{
$ordonnance = new Ordonnance(
dateEmission: new DateTimeImmutable('-13 months'),
reference: 'DM-2201'
);
$this->assertFalse((new ValidateurOrdonnance())->estValide($ordonnance));
}
public function test_une_reference_produit_differente_de_la_prescription_est_refusee(): void
{
$ordonnance = new Ordonnance(referenceProduit: 'DM-2201');
$this->assertFalse(
(new ValidateurOrdonnance())->correspondAuProduit($ordonnance, 'DM-3105')
);
}
}
Ce que la couche intégration couvre
La traçabilité de lot, elle, ne se teste pas unitairement : elle implique la base de données, plusieurs statuts de commande successifs, et l’appel à un service externe simulé de vérification pharmaceutique. Ces tests utilisent WP_UnitTestCase avec des factories dédiées au domaine médical, et interceptent l’appel externe via pre_http_request.
Le bout en bout, réservé à ce qui compte vraiment
Avec seulement 20 % de l’effort alloué au bout en bout, les parcours couverts sont volontairement limités aux deux scénarios à plus fort enjeu réglementaire : un achat complet avec ordonnance valide, et un rappel de lot déclenché depuis l’administration, qui doit notifier automatiquement chaque client ayant acheté un produit du lot concerné.
Sur un projet réglementé, la pyramide de tests ne se calque pas sur l’habitude de l’agence : elle se calque sur l’endroit où se situe réellement le risque, qui n’est pas toujours dans le tunnel de paiement.
Notre verdict
Cette répartition 45/35/20 n’a rien d’universel et ne prétend pas remplacer la pyramide générique déjà utilisée sur d’autres projets d’agence : elle répond spécifiquement à un contexte où la complexité métier se situe dans la validation documentaire et la traçabilité, pas dans le calcul du panier. Adapter la forme de la pyramide au risque réel du projet, plutôt qu’à une habitude, reste la vraie leçon à retenir de ce cas.
