Notre pipeline de test de module Hyvä : 50 migrations nous ont appris cela

Chaque module compatible Hyvä que nous expédions passe par un pipeline de test en quatre étapes avant d'être mis en ligne dans le catalogue. Nous avons construit ce pipeline de manière itérative à partir de plus de 50 migrations Hyvä et d'environ 200 installations de modules. Cet article présente l'architecture de ce pipeline, ce que chaque étape détecte et ce que nous construirions différemment si nous devions recommencer.

Étape 1 : le magasin de référence

Chaque module est d'abord installé sur un magasin de référence Hyvä propre. La référence est Magento Open Source 2.4.7 plus Hyvä Themes 1.3 plus Hyvä Checkout. Le catalogue contient 200 produits dans 6 catégories avec un poids média réaliste. Aucun autre module tiers.

Le magasin de référence est l'environnement le plus propre possible. Si un module échoue ici, le problème vient du module, pas du code environnant. Le magasin de référence détecte : les erreurs au moment de l'installation, les conflits XML de mise en page avec Hyvä, les dépendances Composer manquantes, les échecs de migration de schéma, les bugs de rendu de l'interface utilisateur admin.

Ce que le magasin de référence ne détecte pas : les conflits de modules tiers, les cas limites de trafic réel, les régressions de performance causées par des effets d'interaction.

Étape 2 : le budget Lighthouse

L'étape 2 exécute le magasin de référence contre des audits mobiles Lighthouse avant et après l'installation du module. Le module passe uniquement si la Performance mobile reste au-dessus de 90 avec le module actif.

Neuf vérifications spécifiques font partie du budget :

1. Temps de blocage total inférieur à 200 ms
2. Largest Contentful Paint inférieur à 2,5 s
3. Cumulative Layout Shift inférieur à 0,1
4. Pas de JavaScript obsolète (polyfills ES5 pour des navigateurs que personne n'utilise)
5. Pas de CSS inutilisé de plus de 20 Ko
6. Ressources bloquant le rendu inférieures à 600 ms
7. Formats d'image actuels (WebP minimum)
8. Pas d'iframes tiers bloquant le rendu
9. Temps de réponse serveur inférieur à 600 ms TTFB

La plupart des modules expédiés passent cette étape. Ceux qui échouent ont tendance à échouer sur les points 1, 4 ou 6. Les audits échoués retournent au développeur avec la trace spécifique de Lighthouse.

Étape 3 : la matrice de conflits de modules tiers

L'étape 3 installe le module contre les 20 modules Magento les plus populaires combinés. Nous maintenons une matrice des modules de compatibilité Hyvä actifs dans cette configuration : panier, paiement, recherche, passerelles de paiement, analyses, consentement RGPD.

La matrice de conflits détecte : les conflits de spécificité CSS, les écrasements de gestionnaires d'événements JavaScript (un module écrasant les liaisons Alpine d'un autre), les conflits de dépendances Composer, les conflits de migration de tables de base de données.

Nous avons détecté des régressions à ce stade qui auraient été expédiées aux clients sans être détectées : un module de suivi de commande qui a échoué lorsqu'il a été installé avec un module de consentement RGPD parce que les deux enregistraient des écouteurs d'événements sur le même crochet de dispatch Magento.

Étape 4 : tests de validation en conditions réelles

La dernière étape exécute le module sur une copie de staging de l'un de nos magasins clients. Catalogue de produits réel, structure de catégorie réelle, flux de panier et de paiement réels. Les tests de validation exécutent les parcours utilisateurs canoniques : accueil → catégorie → produit → ajouter au panier → paiement → commande passée.

Cette étape détecte : les cas limites spécifiques aux catalogues réels (produits configurables avec des structures d'attributs inhabituelles, produits avec plus de 50 éléments multimédias, catégories avec plus de 5000 produits), l'impact sur la performance dans des conditions réelles sous charge de cache, les bugs au niveau de l'intégration qui n'apparaissent qu'avec des volumes de données réalistes.

Nous faisons tourner quel magasin client héberge les tests de l'étape 4. Le propriétaire est informé et compensé pour les coûts de l'environnement de staging. Le magasin ne subit jamais d'impact visible pour le client en production car les tests se déroulent sur un clone de staging.

Ce que nous construirions différemment

Trois choses que nous avons apprises en cours de route que nous changerions si nous devions reconstruire à partir de zéro.

Magasin de référence à chaque nouvelle version mineure de Magento. Nous reconstruisons le magasin de référence une fois par version majeure de Magento (2.4.6, 2.4.7) mais pas sur les correctifs mineurs. Nous devrions reconstruire à chaque version mineure car les versions de correctifs changent parfois le comportement de manière à affecter la compatibilité des modules.

Versionnage des modules par rapport à la version de Magento testée. Chaque version de module devrait déclarer exactement contre quelle version de correctif Magento elle a été testée. Nous le faisons de manière lâche dans le changelog ; nous devrions le faire formellement dans la déclaration de dépendance Composer.

Régression automatisée pour les principaux cas d'utilisation des clients. L'étape 4 est actuellement des tests de validation manuels. L'automatisation Cypress contre trois magasins clients détecterait les régressions plus rapidement et réduirait la charge de l'environnement de staging sur ces clients.

Pourquoi nous publions cela

Le catalogue de modules Magento compte trop de fournisseurs qui expédient du code sans infrastructure de test. Des pages de notre blog comme le post sur le bloqueur d'expédition de module Lighthouse 90 expliquent notre politique ; cet article explique le pipeline qui l'applique.

Si vous êtes un magasin Magento évaluant des modules, demandez à votre fournisseur potentiel à quoi ressemble leur pipeline de test. Si la réponse est vague, le module n'a probablement pas été testé contre votre version spécifique de Magento, votre variante spécifique de Hyvä, ou votre ensemble spécifique d'autres modules tiers. C'est un risque que vous portez, pas eux.

Liens connexes

• Post sur le bloqueur d'expédition de module Lighthouse 90 couvre la politique.
• Guide d'achat d'extensions Magento est le cadre pour les acheteurs.