Comment tester correctement les modules PrestaShop

Pourquoi nous testons chaque module sur toutes les versions PrestaShop prises en charge avant de l'expédier

Nous diffusons plus de 140 modules depuis mypresta.rocks, et chacun d'eux passe par PS 1.7.6, 1.7.8, 8.x et 9.x sur des conteneurs de développement dédiés avant que le ZIP de la version ne quitte notre serveur. Nous n'avons pas commencé ainsi. Au départ, nous faisions confiance au fait que « testé sur PS 1.7 » voulait dire quelque chose. Puis nous avons expédié un module qui fonctionnait sur 1.7.8 et affichait un écran blanc sur 1.7.6 parce que la signature de StockAvailable::getQuantityAvailableByProduct avait changé en cours de version mineure. C'est le jour où nous avons construit notre banc de test multi-conteneurs.

Cette page décrit le flux de travail que nous utilisons réellement, pour nos propres versions et pour les clients qui testent des modules tiers sur leurs boutiques. Elle privilégie les tests qui détectent de vrais bugs, et non ceux qui ont l'air rigoureux sur le papier.

Le bug le moins coûteux est celui que votre conteneur de développement détecte à 15 h. Le plus coûteux est celui qu'un client signale un vendredi soir sur une boutique en production. Chaque étape ci-dessous existe parce que nous l'avons payée au prix fort.

Avant l'installation : les trois vérifications qui comptent

La plupart des tickets « ce module a cassé ma boutique » que nous voyons auraient pu être évités en lisant trois choses au préalable. Aucune ne prend plus de cinq minutes.

La compatibilité de version exacte, pas la version majeure

« Compatible avec PrestaShop 1.7 » ne vous apprend presque rien. PS 1.7.0 et 1.7.8 sont séparés par cinq ans et plusieurs changements de cœur incompatibles. Idem pour 8.0 et 8.2. Ouvrez le config.xml ou le composer.json du module et regardez ps_versions_compliancy :

<ps_versions_compliancy>
    <min>1.7.6.0</min>
    <max>9.0.99</max>
</ps_versions_compliancy>

Si votre boutique est en dessous du minimum ou au-dessus du maximum, l'installation échouera purement et simplement, ou pire, elle réussira et plantera plus tard sur un hook dont le module supposait l'existence.

La version de PHP, c'est la même histoire. Un module écrit pour PHP 8.1+ utilisant des propriétés typées et des classes readonly produira une erreur fatale sur PHP 7.4 avec une erreur d'analyse avant même que PrestaShop ne se charge. Vérifiez la version de PHP de votre boutique dans Paramètres avancés → Informations et comparez-la aux exigences du module.

Le nombre de surcharges

Décompressez le module et examinez le répertoire override/. Si vous y voyez override/classes/Cart.php, override/controllers/front/OrderController.php, quoi que ce soit en fait, c'est le plus grand prédicteur de conflits avec tout ce que vous avez déjà installé. Deux modules ne peuvent pas surcharger la même méthode. Le second installé échoue tout simplement.

Les modules basés sur les hooks sont presque toujours plus sûrs que ceux basés sur les surcharges. Si la description du module indique « utilise des surcharges » et que vous avez déjà un module de tunnel de commande, un module SEO ou quoi que ce soit qui touche à Cart ou Product, attendez-vous à des problèmes.

Ce qu'il accroche réellement

Ouvrez le fichier PHP principal du module et recherchez registerHook. La liste vous indique exactement où ce module va s'injecter. Un « simple module de bannière » qui s'enregistre sur actionFrontControllerSetMedia, displayHeader, actionCartSave et actionValidateOrder n'est pas un simple module de bannière. Il fait des choses que vous devriez connaître avant de l'installer.

L'environnement de préproduction doit correspondre à la production

Un site de préproduction « suffisamment proche » de la production n'est pas de la préproduction, c'est une autre boutique qu'il se trouve que vous possédez aussi. L'intérêt est de reproduire les conditions exactes que le module rencontrera sur le site en production. Si votre préproduction tourne sous PHP 8.1 et que la production tourne sous 7.4, vos tests ne prouvent rien.

Notre règle pour la préproduction client : même PHP, même PrestaShop, même thème, mêmes modules, même base de données (rafraîchie au cours des sept derniers jours), même serveur web. Nous utilisons des conteneurs Docker par boutique précisément parce qu'ils rendent cela trivial, `docker compose` met en place un environnement identique en moins d'une minute. Consultez notre guide du site de préproduction pour la configuration que nous utilisons.

Le flux de travail de test

Phase 1 : sauvegarde, même en préproduction

Oui, même en préproduction. Vous êtes sur le point de passer 30 minutes à tester, perdre la base de données à cause d'une installation ratée signifie recloner la production, ce qui est la partie lente. Effectuez d'abord un export :

# Natif
mysqldump -u root -p prestashop > ~/backup_before_module.sql

# Docker (correspond à notre façon de l'exécuter)
sudo docker exec <your-shop>-db mysqldump -u root -p'password' prestashop > ~/backup_before_module.sql

Et profitez-en pour faire un instantané du répertoire modules/. Si l'installateur du module dépose des fichiers dans les répertoires d'autres modules (oui, nous avons vu cela), c'est l'instantané des fichiers qui vous sauvera.

Phase 2 : installer et surveiller les journaux

Ne vous contentez pas de téléverser et de cliquer un peu partout. Surveillez var/logs/ pendant que l'installateur s'exécute :

tail -f var/logs/*.log

Si l'installateur échoue, vous voulez l'erreur réelle, pas un « échec de l'installation du module » en rouge. Les échecs courants que nous voyons : extensions PHP manquantes (intl, gd, curl), permissions de fichiers insuffisantes sur modules/, doublons de slugs de rôle dans ps_authorization_role hérités d'une installation précédente ratée. Le dernier cas est la raison pour laquelle notre script interne nuke-module.sh existe, il nettoie en profondeur toute trace d'un module pour que l'installation suivante reparte de zéro.

Phase 3 : tests fonctionnels : ce que le module prétend faire

Parcourez la liste des fonctionnalités du module, point par point. La page de configuration se charge, les réglages persistent après enregistrement, chaque fonctionnalité documentée fait réellement ce qu'elle annonce. Vérifiez la position du menu dans le back-office que la documentation a promise. Changez la langue du back-office et vérifiez que les traductions existent pour celle que votre équipe utilise.

Ensuite le front-office : visitez chaque type de page que le module est censé affecter. Ouvrez les outils de développement, surveillez la console pour les erreurs JavaScript, surveillez l'onglet Réseau pour les requêtes échouées et les 404 sur les propres ressources du module. Un module qui ajoute views/css/style.css via des balises <link> brutes au lieu de registerStylesheet ne bénéficiera pas du contournement de cache, c'est une 404 en attente la prochaine fois que vous viderez le cache.

Phase 4 : tests de non-régression : qu'est-ce qui d'autre s'est cassé

C'est l'étape que tout le monde saute et c'est elle qui détecte plus de bugs que toutes les autres phases réunies. Le module fonctionne. Maintenant : tout le reste fonctionne-t-il encore ?

Nos modules checkout-revolution et performance-revolution touchent suffisamment au panier et au pipeline de rendu pour que nous disposions d'un script de non-régression fixe pour eux, six parcours que nous exécutons à chaque version :

1. Ajouter au panier depuis une page produit, depuis une liste de catégorie et depuis les résultats de recherche. Trois endroits parce qu'ils sollicitent trois contrôleurs différents.
2. Effectuer un tunnel de commande de bout en bout avec un vrai moyen de paiement et vérifier que la commande apparaît dans l'administration avec les bons totaux.
3. Inscrire un nouveau client et confirmer que l'e-mail de bienvenue se déclenche.
4. Rechercher un produit par son nom, par sa référence et par son EAN.
5. Le détail d'une commande dans l'administration s'ouvre proprement, aucune notice PHP, aucun onglet cassé, aucune information de transporteur manquante.
6. Vider le panier, se déconnecter, se reconnecter avec le même client et confirmer que l'historique est intact.

Si le tunnel de commande fonctionne de bout en bout, vous avez fait l'essentiel du chemin. La plupart des conflits de modules apparaissent pendant le tunnel de commande, car c'est là que le plus de hooks se déclenchent, que le plus de JavaScript s'exécute et que le plus de points de terminaison AJAX sont sollicités sur une seule page.

Phase 5 : performance : ouvrez l'onglet Réseau

Certains modules ajoutent une surcharge bien réelle. Nous avons audité des boutiques où un seul module de « preuve sociale » ajoutait 1,4 seconde de TTFB parce qu'il faisait un appel d'API externe synchrone à l'intérieur de hookDisplayHeader. Le genre de chose qui ruine les Core Web Vitals et qui apparaît dans la Search Console six semaines plus tard.

Trois vérifications rapides avant d'accepter le module :

• L'onglet Réseau des outils de développement : quelles nouvelles requêtes le module ajoute-t-il, et quelle est leur taille ? Un paquet JS de 300 Ko sur chaque page n'est pas gratuit.
• Le temps de traitement côté serveur : installez brièvement avec le mode débogage, regardez l'onglet « Performance » de la barre d'outils Symfony. Les hooks de module qui prennent plus de 50 ms chacun méritent un examen plus attentif.
• Les appels externes à l'intérieur des hooks : recherchez dans le module curl_exec, file_get_contents('http, fopen('http. Un appel sortant synchrone depuis n'importe quel hook qui se déclenche lors d'un rendu de page est un signal d'alarme immédiat.

Tester les mises à jour de modules

Les mises à jour sont généralement plus risquées que les installations neuves. Avec les installations neuves, vous en maîtrisez le moment. Les mises à jour peuvent survenir via une auto-mise à jour ou via les installations en un clic de l'Addons Marketplace et vous surprendre.

Lisez le journal des modifications avant de cliquer sur mettre à jour. S'il mentionne des changements de schéma de base de données, exécutez la mise à niveau d'abord en préproduction et vérifiez que upgrade/install-X.Y.Z.php s'exécute réellement. Les mises à niveau incomplètes sont la source numéro un des tickets « le module est cassé après la mise à jour » que nous traitons. Après la mise à jour, videz le cache Smarty et l'index des classes ensemble :

rm -rf var/cache/prod/*
rm -f var/cache/prod/class_index.php

Puis exécutez l'intégralité de la non-régression de la phase 4. L'instinct du « je viens de mettre à jour, qu'est-ce qui pourrait casser » est trompeur. Des réglages peuvent être perdus, des configurations par défaut peuvent être écrasées, et des surcharges peuvent cesser de fonctionner silencieusement lorsque la signature de la méthode parente change.

Les tests multi-versions : comment nous procédons réellement

Pour les développeurs qui diffusent des modules sur plusieurs versions de PS, la seule réponse honnête est : des conteneurs dédiés par version. Nous faisons tourner quatre pistes de version simultanément :

Notre flux de publication fait passer le module par ces quatre pistes avant que le ZIP ne soit validé. Le choix du conteneur compte : une affirmation « compatible PS 9 » d'un éditeur qui n'a testé que sur 9.0 ne veut presque rien dire. 9.1 A introduit des changements incompatibles dans l'arbre du catalogue et a supprimé plusieurs hooks hérités. Nous utilisons notre commande certify pour analyser le ZIP construit à la recherche d'appels d'API dépréciés avant qu'il ne soit autorisé dans releases/.

Quand quelque chose se passe mal en préproduction

Le back-office est inaccessible après l'installation

Pas de panique, et ne réinstallez pas PrestaShop. Connectez-vous en SSH, renommez le répertoire du module pour l'écarter, et videz le cache :

mv modules/badmodule modules/badmodule_disabled
rm -rf var/cache/prod/* var/cache/dev/*

Le back-office devrait revenir. Récupérez maintenant l'erreur dans var/logs/ et envoyez-la à l'éditeur. Ce sont les données dont il a besoin pour la corriger. Un éditeur qui ne peut pas reproduire à partir d'une ligne de journal est un éditeur qui ne dispose pas d'une boutique de développement correspondant à votre version. Considérez cela comme une donnée pour décider de continuer ou non à faire appel à lui.

Écran blanc sur le front-office

Modifiez config/defines.inc.php et basculez _PS_MODE_DEV_ sur true. Rechargez. Vous obtiendrez la véritable trace de la pile. Lisez le chemin du fichier dans la trace, s'il se trouve dans le nouveau module, voilà votre coupable ; s'il est dans le cœur mais que les paramètres semblent erronés, vous avez probablement affaire à un bug de valeur de retour de hook (du code de hook d'action accidentellement enregistré sur un hook d'affichage, ou l'inverse).

Rebasculez le mode développement sur false dès que vous avez ce qu'il vous faut. Les boutiques en production avec le mode développement activé exposent les traces de pile et, sur PS 9, divulgueront les identifiants de base de données dans les pages d'erreur.

Deux modules entrent en conflit

La bissection est fastidieuse mais fiable. Désactivez les deux. Activez A. Exécutez la non-régression complète de la phase 4. Activez B. Exécutez à nouveau la phase 4. Si cela ne casse qu'avec les deux actifs, vous avez affaire à l'une de trois choses : la même position de hook d'affichage qui se dispute, la même classe du cœur surchargée par les deux, ou des bibliothèques JS concurrentes (versions différentes de jQuery ou deux frameworks CSS revendiquant tous deux .container).

Les conflits de surcharge inscrivent une ligne que vous pouvez rechercher :

grep "is already overridden" var/logs/*.log

La solution consiste en une fusion manuelle. Ouvrez les deux fichiers de surcharge, combinez la logique, installez le second module, supprimez var/cache/prod/class_index.php. Documentez ce que vous avez fusionné. La prochaine fois que l'un ou l'autre module sera mis à jour, vous devrez refaire la fusion.

Tests automatisés pour les développeurs de modules

Si vous écrivez des modules (et pas seulement si vous les installez), l'investissement dans les tests se rentabilise vite. Voici ce que nous exécutons réellement.

PHPUnit pour toute classe dont la logique est séparable de PrestaShop. Tokeniseurs, calculateurs, formateurs, planificateurs. Simulez les appels PrestaShop à la frontière ; testez la logique métier sans démarrer de boutique. Nous les exécutons à chaque commit via notre flux ship avant même que le ZIP ne soit construit.

Playwright pour les tests de fumée du front-office. Ajout au panier, tunnel de commande, connexion. Le genre de test qui détecte « votre nouvelle version a cassé le bouton d'achat » avant qu'un client ne le fasse. Nous maintenons leur durée totale d'exécution sous 30 secondes. Tout ce qui est plus lent cesse d'être exécuté.

GitHub Actions pour câbler le tout. Lorsque vous poussez un commit, le flux de travail démarre PS 1.7.8 et PS 9.1 dans des conteneurs, installe le module, exécute PHPUnit, exécute la suite Playwright, puis exécute notre commande certify sur le ZIP construit pour signaler les appels d'API PrestaShop dépréciés. Si le moindre voyant rouge s'allume, le ZIP de la version ne se génère pas.

La liste de contrôle que nous utilisons réellement

Épinglée au mur au-dessus de notre baie de développement. Douze points, dans l'ordre. Nous ne diffusons pas une version tant que chaque ligne n'est pas au vert.

Chaque module de mypresta.rocks est livré avec une démo gratuite de 30 jours pour que vous puissiez exécuter cette liste de contrôle sur votre propre préproduction avant de payer quoi que ce soit. Exécutez-la. Si quelque chose échoue, dites-le-nous, c'est exactement le retour qui améliore la version suivante.

Lectures complémentaires

• Comment créer un site de préproduction PrestaShop : l'environnement de test dont dépend tout ce flux de travail
• Outils essentiels pour le développement PrestaShop : ce que nous utilisons au quotidien pour inspecter les modules
• Développement local PrestaShop : configuration XAMPP, WAMP, Docker et Linux : configuration de conteneur local correspondant à la nôtre
• Hooks et surcharges PrestaShop : comprendre le système de hooks auquel se rattachent la plupart des bugs de modules

Modules associés

• Performance Revolution : détecter les régressions de performance avant la publication
• MPR Checkout Revolution : tester en non-régression l'intégralité du parcours de commande
• Issue Tracker : consigner des rapports de bugs reproductibles issus des tests

Questions liées

• Le module affiche « This module requires PHP X.Y », puis-je quand même l’installer ?
• J'ai téléversé le module, mais PrestaShop affiche « Unable to install module. »
• Le debugging performance peut-il être limité ?
• Comment activer le mode debug dans PrestaShop ?
• La configuration de mon module ne s'enregistre pas.
• Le module affiche une erreur « Class not found » ou « Namespace not found ».