Tester un module avant de le mettre en production

Ce qu’une copie de test permet réellement de voir

Une copie fidèle de la boutique, sur une adresse séparée, permet trois choses qu’aucune lecture de fiche produit ne donne : constater l’effet réel du module sur vos données et pas sur un catalogue de démonstration, mesurer son coût sur le temps de génération des pages, et faire les manipulations destructives — désactiver, désinstaller, recommencer — sans conséquence commerciale.

C’est aussi le seul endroit où l’on peut vérifier l’interaction avec les modules déjà installés. Un module se comporte différemment seul et au milieu de quinze autres, et cette différence ne s’observe que sur une copie du site tel qu’il est vraiment.

Les trois pièges d’une préproduction

La licence liée au domaine. Beaucoup de modules commerciaux vérifient le nom de domaine sur lequel ils tournent. Sur une adresse de test, le module peut refuser de s’activer, ou s’activer en mode dégradé. Il faut vérifier avant si la licence couvre une installation de test : certains éditeurs le prévoient explicitement, d’autres non.

Les données de production copiées telles quelles. Une copie contient de vraies adresses, de vrais e-mails et de vraies commandes. Il faut couper l’envoi d’e-mails et désactiver les paiements réels avant la première manipulation, sinon un test de commande déclenche un vrai message vers un vrai client.

Les différences d’environnement. Un module qui fonctionne en test et pas en production révèle presque toujours un écart de version de PHP, d’extensions installées ou de configuration serveur. Une préproduction utile est une préproduction identique, pas une préproduction approximative.