Unsere Hyvä-Modul-Testpipeline: 50 Migrationen haben uns das gelehrt
Jedes Hyvä-kompatible Modul, das wir versenden, durchläuft eine vierstufige Testpipeline, bevor es im Katalog live geht. Diese Pipeline haben wir iterativ über 50+ Hyvä-Migrationen und ungefähr 200 Modulinstallationen aufgebaut. Dieser Beitrag beschreibt die Architektur dieser Pipeline, was jede Stufe erfasst und was wir anders bauen würden, wenn wir von vorne anfangen würden.
Stufe 1: der Referenzshop
Jedes Modul wird zunächst in einem sauberen Hyvä-Referenzshop installiert. Die Referenz ist Magento Open Source 2.4.7 plus Hyvä Themes 1.3 plus Hyvä Checkout. Der Katalog enthält 200 Produkte in 6 Kategorien mit realistischen Mediengewichten. Keine anderen Drittanbieter-Module.
Der Referenzshop ist die sauberste mögliche Umgebung. Wenn ein Modul hier fehlschlägt, liegt das Problem am Modul und nicht am umgebenden Code. Der Referenzshop erfasst: Installationsfehler, Layout-XML-Konflikte mit Hyvä, fehlende Composer-Abhängigkeiten, Schema-Migrationsfehler, Rendering-Bugs in der Admin-Oberfläche.
Was der Referenzshop nicht erfasst: Konflikte mit Drittanbieter-Modulen, Edge Cases im echten Verkehr, Leistungsrückgänge, die durch Wechselwirkungen verursacht werden.
Stufe 2: das Lighthouse-Budget
Stufe 2 führt den Referenzshop vor und nach der Modulinstallation gegen Lighthouse-Mobile-Audits aus. Das Modul besteht nur, wenn die mobile Leistung mit aktivem Modul über 90 bleibt.
Neun spezifische Prüfungen sind Teil des Budgets:
- Gesamte Blockierungszeit unter 200 ms
- Largest Contentful Paint unter 2,5 s
- Kumulative Layout-Verschiebung unter 0,1
- Kein veraltetes JavaScript (ES5-Polyfills für Browser, die niemand nutzt)
- Kein ungenutztes CSS über 20 KB
- Render-blockierende Ressourcen unter 600 ms
- Bildformate aktuell (mindestens WebP)
- Keine render-blockierenden Drittanbieter-iFrames
- Serverantwort unter 600 ms TTFB
Die meisten Modulversendungen bestehen diese Stufe. Die, die scheitern, haben oft Probleme bei Punkt 1, 4 oder 6. Fehlgeschlagene Audits werden mit dem spezifischen Lighthouse-Trace an den Entwickler zurückgegeben.
Stufe 3: die Konfliktmatrix für Drittanbieter-Module
Stufe 3 installiert das Modul in Kombination mit den 20 beliebtesten Magento-Modulen. Wir führen eine Matrix, welche Hyvä-Kompatibilitätsmodule in dieser Konfiguration aktiv sind: Warenkorb, Checkout, Suche, Zahlungs-Gateways, Analytik, GDPR-Zustimmung.
Die Konfliktmatrix erfasst: CSS-Spezifitätskonflikte, JavaScript-Ereignis-Handler-Überschreibungen (ein Modul überschreibt die Alpine-Bindungen eines anderen), Composer-Abhängigkeitskonflikte, Konflikte bei der Migration von Datenbanktabellen.
Wir haben in dieser Phase Rückschritte festgestellt, die unentdeckt an Kunden ausgeliefert worden wären: ein Checkout-Tracking-Modul, das zusammen mit einem GDPR-Zustimmungsmodul fehlschlug, weil beide Ereignis-Listener am selben Magento-Dispatch-Hook registriert wurden.
Stufe 4: Smoke-Tests im echten Shop
Die letzte Stufe führt das Modul auf einer Staging-Kopie eines unserer Kunden-Shops aus. Echter Produktkatalog, echte Kategorienstruktur, echte Warenkorb- und Checkout-Abläufe. Smoke-Tests führen die kanonischen Benutzerreisen aus: Startseite → Kategorie → Produkt → In den Warenkorb → Checkout → Bestellung aufgegeben.
Diese Stufe erfasst: Edge Cases, die spezifisch für reale Kataloge sind (konfigurierbare Produkte mit ungewöhnlichen Attributstrukturen, Produkte mit über 50 Medienobjekten, Kategorien mit über 5000 Produkten), reale Leistungsbeeinträchtigungen unter echter Cache-Ladung, Integrationsfehler, die nur bei realistischen Datenmengen auftreten.
Wir rotieren, welcher Kunden-Shop die Stufe-4-Tests hostet. Der Eigentümer wird informiert und für die Kosten der Staging-Umgebung entschädigt. Der Shop sieht niemals Auswirkungen auf die Produktion, da die Tests auf einem Staging-Klon durchgeführt werden.
Was wir anders bauen würden
Drei Dinge, die wir auf dem Weg gelernt haben und die wir ändern würden, wenn wir von Grund auf neu bauen würden.
Referenzshop bei jedem Magento-Minor-Release. Wir bauen den Referenzshop einmal pro major Magento-Version (2.4.6, 2.4.7) neu auf, aber nicht bei Minor-Patches. Wir sollten bei jedem Minor-Release neu aufbauen, da Patch-Releases gelegentlich das Verhalten in einer Weise ändern, die die Modulkompatibilität beeinflusst.
Modulversionierung gegen getestete Magento-Version. Jede Modulversion sollte genau angeben, gegen welche Magento-Patch-Version sie getestet wurde. Wir tun dies lose im Änderungsprotokoll; wir sollten es formell in der Composer-Abhängigkeitsdeklaration tun.
Automatisierte Regression für die wichtigsten Kundenanwendungsfälle. Stufe 4 sind heute manuelle Smoke-Tests. Cypress-Automatisierung gegen drei Kunden-Shops würde Rückschritte schneller erfassen und die Belastung der Staging-Umgebung für diese Kunden reduzieren.
Warum wir das veröffentlichen
Der Magento-Modulkatalog hat zu viele Anbieter, die Code ohne Testinfrastruktur versenden. Seiten in unserem Blog wie der Lighthouse 90 Modul-Ship-Blocker-Beitrag erklären unsere Richtlinie; dieser Beitrag erklärt die Pipeline, die sie durchsetzt.
Wenn Sie ein Magento-Shop sind, der Module evaluiert, fragen Sie Ihren potenziellen Anbieter, wie ihre Testpipeline aussieht. Wenn die Antwort vage ist, wurde das Modul wahrscheinlich nicht gegen Ihre spezifische Magento-Version, Ihre spezifische Hyvä-Variante oder Ihren spezifischen Stapel anderer Drittanbieter-Module getestet. Das ist ein Risiko, das Sie tragen, nicht sie.
Verwandt
- Lighthouse 90 Modul-Ship-Blocker-Beitrag behandelt die Richtlinie.
- Magento-Erweiterungskäuferleitfaden ist der Rahmen für Käufer.