Avant de se demander comment tester ses modules sur plusieurs versions de PrestaShop, la question serait plutôt de se demander pourquoi. La réponse reste assez simple. Vos utilisateurs utilisent la solution open source sur leurs propres serveurs et peuvent donc être sur des versions de PrestaShop totalement différentes.
Mais qu’est-ce que je risque à ne pas vérifier la compatibilité ? Les risques sont multiples :
- Augmentation du support
- Baisse de votre note (si vous vendez sur une marketplace)
- Baisse de la réputation de votre module (et donc votre propre réputation)
Comment vérifier sa compatibilité ?
Pour vérifier la compatibilité d’un module, il y a une première étape : la mise d’une analyse statique du code pour vérifier que le code de votre module est compatible avec le code du Core.
Je vous recommande l’article de Jonathan Danse : Tester et analyser ses modules automatiquement.
Votre code est désormais compatible avec PrestaShop. Mais est-ce que le comportement est identique sur toutes les versions de PrestaShop que votre module supporte ? Pour répondre à cette question, c’est la deuxième étape : la mise en place de tests automatisés.
Quels outils pour tester vos modules ?
Pour tester le comportement de vos modules, je ne vais pas m’attendre à ce que vous installiez tous les jours chaque version de PrestaShop. On va essayer d’automatiser tout cela.
Il faudra :
- un environnement de test : on partira sur Docker ;
- une plateforme de test : on partira sur Github Actions (mais la technique s’appliquera aussi à Gitlab CI) ;
- une librairie de test : on partira sur
@playwright/test
embarqué dans@prestashop-core/ui-testing
.
Quels processus dois je mettre en place ?
Définition de la campagne de tests
Votre campagne comporte l’ensemble des tests que vous effectuez manuellement.
Je vais vous donner deux exemples (qui sont souvent la base des tests de module) :
- Installation du module
- Vérification des paramètres par défaut
- Vérification que le module est hooké sur les bons hooks
- Désinstallation du module
- Vérification que le module n’est plus disponible sur les hooks
Évidemment votre module n’a rarement comme seules fonctionnalités l’installation et la désinstallation. A partir de l’ensemble des actions de votre module, vous pouvez définir l’ensemble des tests que vous voulez effectuer sur votre module. Après avoir pensé à chaque action de votre module, n’hésitez pas à repasser sur chaque ticket de support que vous avez eu pour compléter vos scénarios.
Définition de la plage de versions de PrestaShop
Vous connaissez les versions de PrestaShop minimale et maximale supportées par votre module.
Il vous ensuite définir quels versions vous voulez tester :
- Uniquement les dernières versions majeures :
1.7.8.11
8.2.0
- Uniquement les dernières versions mineures :
1.7.1.2
1.7.2.5
1.7.3.4
1.7.4.4
1.7.5.2
1.7.6.9
1.7.7.8
1.7.8.11
8.0.5
8.1.5
8.2.0
- Sur chaque version mineure
- Sur la prochaine version (
nightly
)
Si votre liste de versions est conséquente, n’hésitez pas à prioriser les versions les plus utilisées par vos clients, ou les versions qui vous envoient le plus de demandes de support.
Définition du workflow
Maintenant, que l’on sait ce que l’on va tester, sur quelles versions de PrestaShop on va le tester, la dernière question à poser est : quand va-t-on le tester ?
Il y a plusieurs possibilités :
- toutes les nuits sur votre branche de développement
- sur chacune des pull-requests (pour vérifier qu’un nouveau développement/bug fix ne casse pas tout)
- uniquement à la demande
Conclusion
Toutes ces questions que vous avez à vous poser sont la base du travail pour apporter plus une compatibilité de qualité à votre module. Les avantages à long terme sont multiples : une satisfaction client qui augmente, et moins de bugs, donc moins de support. Dans un prochain article, nous allons mettre en place cette architecture sur un module.