Migrer vers Sylius 2 sans tests automatisés ?
Oui, on peut migrer vers Sylius 2 sans couverture de tests complète, et c'est même la situation la plus courante : une boutique sur mesure avec des tests exhaustifs est l'exception. Ce n'est pas une raison pour reporter, mais il faut compenser. Avant de toucher au code, je construis un filet de sécurité ciblé sur les parcours qui rapportent de l'argent, quelques tests automatisés qui passent par les pages plutôt que par les classes internes, et je couvre le reste par une recette manuelle écrite, jouée sur une copie des données réelles.
Je suis développeur Sylius indépendant. Quand un dirigeant ou un responsable technique m'annonce, un peu gêné, que sa boutique n'a pas de tests, je lui réponds la même chose : l'absence de tests ne bloque pas la migration, elle change la façon de la sécuriser et le temps de recette à prévoir.
Pourquoi une couverture complète n'est-elle pas nécessaire ?
Une couverture de tests complète sert à protéger chaque ligne de code contre une modification future. Une migration a un objectif plus étroit : prouver que ce que vos clients et vos équipes font tous les jours marche encore après le changement. Ce périmètre est limité et connu. Rechercher un produit, filtrer une catégorie, ajouter au panier, appliquer un code promo, choisir une livraison, payer, recevoir l'e-mail de confirmation, voir la commande dans l'administration, l'expédier, l'exporter vers vos outils. C'est cette liste qu'il faut protéger, pas l'ensemble du code.
Écrire tous les tests manquants avant de migrer serait d'ailleurs contre-productif : ce chantier serait souvent plus long que la migration elle-même, et une partie des tests serait à réécrire juste après, puisque Sylius 2 supprime ou déplace de nombreuses classes.
Quel filet de sécurité construire avant de migrer ?
Le principe qui compte le plus est de tester par l'extérieur. Un test qui appelle directement une classe interne de Sylius 1 risque de casser en même temps que le code qu'il protège, simplement parce que la classe a été supprimée ou renommée. Un test qui charge une page, remplit un formulaire et vérifie le résultat, lui, reste valable des deux côtés de la migration. Il est écrit une fois sur la 1.14, il passe au vert, puis il sert de juge sur la version 2.
Les tests de fumée sur toutes les pages importantes
C'est le premier niveau, et le plus rentable. Un test qui charge la page d'accueil, une catégorie, une fiche produit, le panier, chaque étape du tunnel de commande, la connexion client et les principaux écrans d'administration, puis vérifie qu'aucune erreur ne remonte. La documentation de Symfony sur les tests décrit ces tests d'application, qui envoient des requêtes à l'application complète et vérifient la réponse avec PHPUnit. Ils s'écrivent vite et détectent immédiatement les régressions bruyantes.
Quelques scénarios complets sur le tunnel de commande
Le second niveau joue une commande de bout en bout : un client invité, un client connecté, chaque moyen de paiement en mode bac à sable, une commande avec promotion. Sylius est lui-même développé avec des scénarios Behat, rédigés en langage naturel, que l'on trouve dans le dossier features de son dépôt. Pour les parties qui reposent sur JavaScript, la documentation de Symfony oriente vers le composant Panther, qui pilote un vrai navigateur. Quelques scénarios bien choisis valent mieux que des dizaines de tests sur des détails.
Des contrôles sur les données
Le troisième niveau ne teste pas des écrans mais des chiffres : nombre de produits, de clients et de commandes avant et après migration de la copie de la base, totaux de commandes, stocks. Ces requêtes de contrôle prennent peu de temps à écrire et rassurent sur l'essentiel : rien n'a été perdu.
Si vous voulez savoir quel filet construire sur votre boutique, je le définis pendant le diagnostic de migration offert, à partir de votre code et de vos vrais parcours de vente.
Que faire quand il n'y a vraiment aucun test ?
On remplace les tests absents par une recette écrite. Pas une liste mentale, ni « on cliquera un peu partout », mais un cahier de recette : chaque parcours, les données à utiliser, le résultat attendu, la personne qui valide. Il est d'abord joué sur la 1.14 pour fixer la référence, puis sur la version 2 avec la même copie des données. Vos équipes y ont leur place, car elles connaissent les cas particuliers que le code ne montre pas : le client professionnel qui commande toujours par trois, la promotion qui revient chaque année, l'export du lundi matin.
Avant même la recette, l'analyse statique compense une partie du manque. Sylius Upgrade Analyzer, l'outil open source que j'ai créé et publié sur le Sylius Store, repère dans le code les gabarits, classes, routes et plugins touchés par la version 2. On ne teste pas au hasard : on teste en priorité là où l'outil signale un changement.
Qu'est-ce que l'absence de tests change pour le délai ?
Elle allonge surtout la recette, pas le développement. Sans tests automatisés, chaque correction faite pendant le chantier doit être revérifiée à la main sur tous les parcours, et ce temps se répète à chaque itération. Le filet de sécurité décrit plus haut a un coût initial en jours, mais il réduit ces vérifications répétées. Je chiffre les deux options séparément pour que vous puissiez arbitrer, comme je l'explique dans l'article sur l'estimation de la durée d'une migration.
Il y a aussi un bénéfice durable. Les tests écrits pour la migration resteront utiles à chaque correctif de sécurité et à chaque montée de version mineure de Sylius 2. La méthode de test complète, couche par couche, est détaillée dans l'article sur comment tester une migration Sylius 1.x vers 2.x.
Ce que je vous propose
Ne laissez pas l'absence de tests retarder la décision : la 1.14 ne reçoit plus de correctifs de sécurité après le 31 décembre 2026. Je lance Sylius Upgrade Analyzer sur votre projet, je définis le filet de tests minimal adapté à votre boutique et la recette à prévoir, et je vous remets un rapport commenté avec une estimation en jours. Je vous rappelle sous 24 heures ouvrées après votre demande.