Comment tester une migration Sylius 1.x vers Sylius 2 ?
Pour tester efficacement une migration de Sylius 1.x vers Sylius 2, il faut procéder par couches : une analyse statique du code qui dit où chercher, des tests automatisés de fumée sur toutes les pages, quelques scénarios complets sur le tunnel de commande, une comparaison entre la 1.14 et la version 2 sur la même copie des données réelles, puis une recette métier faite par vos équipes. Les fonctionnalités qui ne marchent plus se repèrent par les écarts entre les deux versions, pas en cliquant au hasard.
Je suis développeur Sylius indépendant et voici la méthode que j'applique sur les montées de version que je mène. Elle convient à un responsable technique qui veut organiser la recette, et elle donne au dirigeant une réponse claire à la seule question qui compte : comment savoir, avant la mise en ligne, que la boutique vend toujours.
Par quoi commencer : l'analyse statique avant les tests
Tester sans savoir où chercher, c'est tester tout avec la même intensité, donc rien assez. La première couche n'est pas un test mais un inventaire. Le guide officiel UPGRADE-2.0 liste plus d'une centaine de classes et interfaces supprimées, des services retirés, des routes de la boutique supprimées, et des changements de configuration sur les pare-feux, les paiements et la machine à états. Croiser cette liste à la main avec votre code prend du temps et laisse passer des oublis.
C'est pour cela que j'ai créé Sylius Upgrade Analyzer, publié en open source sur le Sylius Store. Ses 49 analyseurs parcourent les gabarits, les classes, les routes, la configuration et les plugins, et produisent un rapport en console, Markdown ou PDF. Chaque point signalé devient une zone à tester en priorité. Le plan de test part de ce rapport, pas d'une liste générique.
Comment identifier les fonctionnalités qui ne fonctionnent plus après migration ?
La méthode la plus fiable est la comparaison. On fait tourner la 1.14 et la version 2 côte à côte, chacune sur la même copie de la base, et on leur pose les mêmes questions.
Comparer les pages et les routes
Je parcours automatiquement toutes les adresses de la boutique (catégories, fiches produits, pages de contenu) sur les deux versions et je compare les codes de réponse. Une page qui répond en 1.14 et renvoie une erreur ou une redirection inattendue en version 2 est une régression, ou une adresse à rediriger. La commande bin/console debug:router, lancée sur les deux versions, met aussi en évidence les routes qui ont disparu, notamment celles que votre JavaScript appelait en Ajax.
Faire parler l'application
Plusieurs régressions se trahissent avant même qu'on clique. Les commandes lint:container et lint:twig de Symfony signalent des services mal configurés et des gabarits invalides. Les journaux d'erreurs et de dépréciations, consultés après chaque série de tests, montrent les appels qui échouent en silence. Les files de messages en échec, utilisées notamment par les demandes de paiement de Sylius 2, doivent rester vides.
Comparer les résultats métier
Le dernier niveau de comparaison porte sur ce qui sort de la boutique : totaux d'un même panier, états de commande après paiement, contenu des e-mails, factures, fichiers exportés vers l'ERP ou la logistique. Un écart sur l'un d'eux signale une fonctionnalité qui ne fonctionne plus comme avant, même si aucune page ne plante. Le cas des commandes, paiements et promotions est assez critique pour que je le traite à part, dans l'article sur la garantie du processus de commande.
Quels tests automatiser en priorité ?
La règle d'or d'une migration est de tester par l'extérieur : un test qui passe par une page ou par l'API reste valable des deux côtés, un test qui appelle une classe interne supprimée casse avec elle. Voici les couches que je mets en place, de la plus rapide à la plus complète.
| Couche | Outil | Ce qu'elle prouve |
|---|---|---|
| Tests de fumée | PHPUnit, tests d'application Symfony | Chaque page importante répond sans erreur |
| Scénarios métier | Behat | Une commande va du panier à l'expédition |
| Parcours avec JavaScript | Panther, navigateur réel | Ajout au panier, choix de déclinaison, paiement |
| API | Tests d'application sur les points d'entrée | Les applications et outils connectés s'authentifient et lisent les mêmes données |
| Données | Requêtes de contrôle | Produits, clients, commandes et stocks sont tous repris |
La documentation de Symfony sur les tests décrit ces niveaux, des tests unitaires aux tests d'application qui envoient de vraies requêtes. Si votre boutique part de zéro sur ce terrain, je détaille le filet minimal dans l'article sur la question de migrer sans couverture de tests complète.
Si vous préférez qu'un regard extérieur établisse ce plan de test sur votre code, c'est l'un des livrables du diagnostic de migration offert.
Pourquoi tester avec une copie des données réelles ?
Les données de démonstration ne révèlent pas les problèmes que vos données réelles contiennent : un produit à plusieurs centaines de déclinaisons, un compte client créé il y a des années avec un ancien hachage de mot de passe, une commande restée dans un état intermédiaire, un attribut saisi de façon inattendue. Sylius 2 retire par exemple le champ salt des comptes utilisateurs : seule une copie réelle permet de vérifier que les anciens clients se connectent encore.
Cette copie contient des données personnelles. Je recommande de l'anonymiser dès qu'elle sort de votre hébergement, et dans tous les cas de neutraliser l'envoi d'e-mails réels et les paiements réels depuis l'environnement de test, pour qu'aucun client ne reçoive de message issu de la recette.
La recette métier par vos équipes, puis la répétition de la bascule
Les tests techniques prouvent que la boutique fonctionne. La recette métier prouve qu'elle fonctionne comme vos équipes l'utilisent. Je prépare un cahier de recette écrit, parcours par parcours, et je le fais jouer au service client, à la logistique et à la comptabilité sur l'environnement de test. Ce sont elles qui signent la validation.
Dernière couche : la bascule elle-même se teste. Je la répète sur une copie fraîche de la production, chronomètre en main, retour arrière compris. Une bascule qui n'a jamais été répétée reste une hypothèse, quelle que soit la qualité des tests qui l'ont précédée.
Ce que je vous propose
Je lance Sylius Upgrade Analyzer sur votre projet et je transforme son rapport en plan de test : zones prioritaires, couches à automatiser, cahier de recette à prévoir. Vous recevez un rapport commenté avec une estimation en jours, et je vous rappelle sous 24 heures ouvrées. La 1.14 ne reçoit plus de correctifs de sécurité après le 31 décembre 2026 : une recette bien préparée est ce qui permet de tenir ce calendrier sans prendre de risque sur vos ventes.