PrestaShop-Module richtig testen

Warum wir jedes Modul vor der Auslieferung über alle unterstützten PrestaShop-Versionen testen

Wir liefern 159 Module von mypresta.rocks aus, und jedes einzelne davon läuft auf dedizierten Dev-Containern durch PS 1.6, 1.7.6, 1.7.8, 8.x und 9.x, bevor die Release-ZIP unseren Server verlässt. Dort haben wir nicht angefangen. Wir haben angefangen, indem wir darauf vertraut haben, dass „getestet auf PS 1.7" etwas bedeutet. Dann haben wir ein Modul ausgeliefert, das auf 1.7.8 funktionierte und auf 1.7.6 einen Weißbildschirm produzierte, weil StockAvailable::getQuantityAvailableByProduct mitten in einer Minor-Version die Signatur geändert hat. An diesem Tag haben wir das Multi-Container-Testsystem aufgebaut.

Diese Seite ist der Arbeitsablauf, den wir tatsächlich verwenden, für unsere eigenen Releases und für Kunden, die Module von Drittanbietern in ihren Shops testen. Er ist auf die Tests ausgerichtet, die echte Fehler aufdecken, nicht auf die Tests, die auf dem Papier gründlich aussehen.

Der billigste Fehler ist der, den Ihr Dev-Container um 15 Uhr abfängt. Der teuerste ist der, den ein Kunde an einem Freitagabend im Live-Shop meldet. Jeder Schritt weiter unten existiert, weil wir auf die harte Tour dafür bezahlt haben.

Vor der Installation: die drei Prüfungen, auf die es ankommt

Die meisten „dieses Modul hat meinen Shop zerstört"-Tickets, die wir sehen, hätten sich verhindern lassen, indem man vorher drei Dinge liest. Keines davon dauert länger als fünf Minuten.

Exakte Versionskompatibilität, nicht die Hauptversion

„Kompatibel mit PrestaShop 1.7" sagt Ihnen so gut wie nichts. Zwischen PS 1.7.0 und 1.7.8 liegen fünf Jahre und mehrere tiefgreifende Änderungen am Core. Dasselbe gilt für 8.0 gegenüber 8.2. Öffnen Sie die config.xml oder die composer.json des Moduls und schauen Sie sich ps_versions_compliancy an:

<ps_versions_compliancy>
    <min>1.7.6.0</min>
    <max>9.0.99</max>
</ps_versions_compliancy>

Wenn Ihr Shop unter dem Minimum oder über dem Maximum liegt, schlägt die Installation direkt fehl, oder schlimmer: Sie wird ausgeführt und stürzt später bei einem Hook ab, dessen Existenz das Modul vorausgesetzt hat.

Mit der PHP-Version verhält es sich genauso. Ein Modul, das für PHP 8.1+ mit typisierten Eigenschaften und readonly-Klassen geschrieben wurde, wird auf PHP 7.4 mit einem Parse-Fehler abstürzen, bevor PrestaShop überhaupt geladen ist. Prüfen Sie die PHP-Version Ihres Shops unter Erweiterte Parameter → Informationen und gleichen Sie sie mit den Anforderungen des Moduls ab.

Anzahl der Overrides

Entpacken Sie das Modul und schauen Sie sich das Verzeichnis override/ an. Wenn Sie dort override/classes/Cart.php, override/controllers/front/OrderController.php oder überhaupt irgendetwas sehen. Das ist der mit Abstand stärkste Indikator für Konflikte mit allem anderen, was Sie bereits installiert haben. Zwei Module können nicht dieselbe Methode überschreiben. Das zweite, das installiert wird, schlägt einfach fehl.

Hook-basierte Module sind fast immer sicherer als override-basierte. Wenn in der Modulbeschreibung steht „verwendet Overrides" und Sie bereits ein Checkout-Modul, ein SEO-Modul oder irgendetwas haben, das Cart oder Product berührt, sollten Sie mit Problemen rechnen.

Was es tatsächlich an Hooks registriert

Öffnen Sie die Haupt-PHP-Datei des Moduls und suchen Sie nach registerHook. Die Liste sagt Ihnen genau, wo sich dieses Modul einklinken wird. Ein „einfaches Banner-Modul", das sich auf actionFrontControllerSetMedia, displayHeader, actionCartSave und actionValidateOrder registriert, ist kein einfaches Banner-Modul, es tut Dinge, von denen Sie vor der Installation wissen sollten.

Die Staging-Umgebung muss mit der Produktion übereinstimmen

Eine Staging-Site, die der Produktion „nah genug" ist, ist kein Staging. Sie ist ein anderer Shop, der Ihnen zufällig auch gehört. Der ganze Sinn besteht darin, exakt die Bedingungen nachzubilden, auf die das Modul auf der Live-Site treffen wird. Wenn Ihr Staging auf PHP 8.1 und die Produktion auf 7.4 läuft, beweisen Ihre Tests nichts.

Unsere Regel für Kunden-Staging: gleiches PHP, gleiches PrestaShop, gleiches Theme, gleiche Module, gleiche Datenbank (innerhalb der letzten sieben Tage aktualisiert), gleicher Webserver. Wir verwenden Docker-Container pro Shop genau deshalb, weil sie das trivial machen, `docker compose` bringt eine identische Umgebung in unter einer Minute hoch. Sehen Sie sich für die von uns verwendete Einrichtung unseren Leitfaden zur Staging-Site an.

Der Test-Arbeitsablauf

Phase 1: Backup, sogar auf Staging

Ja, sogar auf Staging. Sie sind im Begriff, 30 Minuten mit Testen zu verbringen, die Datenbank durch eine missglückte Installation zu verlieren, bedeutet, die Produktion neu zu klonen, und das ist der langsame Teil. Erstellen Sie zuerst einen Dump:

# Nativ
mysqldump -u root -p prestashop > ~/backup_before_module.sql

# Docker (so wie wir es ausführen)
sudo docker exec <your-shop>-db mysqldump -u root -p'password' prestashop > ~/backup_before_module.sql

Und erstellen Sie gleich noch einen Schnappschuss des Verzeichnisses modules/. Wenn der Installer des Moduls Dateien in die Verzeichnisse anderer Module ablegt (ja, das haben wir schon gesehen), ist der Datei-Schnappschuss das, was Sie rettet.

Phase 2: installieren und die Logs beobachten

Laden Sie nicht einfach hoch und klicken Sie herum. Verfolgen Sie var/logs/ mit, während der Installer läuft:

tail -f var/logs/*.log

Wenn der Installer fehlschlägt, möchten Sie den tatsächlichen Fehler sehen, nicht nur „Modulinstallation fehlgeschlagen" in Rot. Häufige Fehler, die wir sehen: fehlende PHP-Erweiterungen (intl, gd, curl), unzureichende Dateiberechtigungen auf modules/, doppelte Rollen-Slugs in ps_authorization_role aus einer vorherigen fehlgeschlagenen Installation. Letzteres ist der Grund, warum unser internes Skript nuke-module.sh existiert, es entfernt gründlich jede Spur eines Moduls, sodass die nächste Installation bei null beginnt.

Phase 3: Funktionstest: was das Modul verspricht

Gehen Sie die Funktionsliste des Moduls Punkt für Punkt durch. Die Konfigurationsseite lädt, Einstellungen bleiben nach dem Speichern erhalten, jede dokumentierte Funktion tut tatsächlich das, was sie verspricht. Prüfen Sie die im Handbuch versprochene Position im Back-Office-Menü. Wechseln Sie die Back-Office-Sprache und stellen Sie sicher, dass Übersetzungen für die von Ihrem Team verwendete Sprache vorhanden sind.

Dann das Front-Office: Besuchen Sie jeden Seitentyp, den das Modul beeinflussen soll. Öffnen Sie die Entwicklertools, beobachten Sie die Konsole auf JavaScript-Fehler, beobachten Sie den Reiter „Netzwerk" auf fehlgeschlagene Anfragen und 404-Fehler bei den eigenen Assets des Moduls. Ein Modul, das views/css/style.css über rohe <link>-Tags statt über registerStylesheet einbindet, erhält keine Cache-Busting-Versionierung. Das ist ein 404-Fehler, der nur darauf wartet, beim nächsten Leeren des Caches aufzutreten.

Phase 4: Regressionstest: was sonst noch kaputtgegangen ist

Das ist der Schritt, den alle überspringen, und er deckt mehr Fehler auf als alle anderen Phasen zusammen. Das Modul funktioniert. Nun: funktioniert alles andere noch?

Unsere Module checkout-revolution und performance-revolution greifen so tief in die Warenkorb- und Rendering-Pipeline ein, dass wir für sie ein festes Regressionsskript haben, sechs Pfade, die wir bei jedem Release durchlaufen:

1. In den Warenkorb legen von einer Produktseite, aus einer Kategorienauflistung und aus den Suchergebnissen. Drei Stellen, weil sie drei verschiedene Controller ansprechen.
2. Einen Checkout durchgängig abschließen mit einer echten Zahlungsart und überprüfen, dass die Bestellung mit den korrekten Summen im Admin-Bereich erscheint.
3. Einen neuen Kunden registrieren und bestätigen, dass die Willkommens-E-Mail ausgelöst wird.
4. Suchen Sie nach einem Produkt anhand des Namens, der Referenz und der EAN.
5. Die Bestelldetails im Admin-Bereich öffnen sich sauber, keine PHP-Hinweise, keine kaputten Reiter, keine fehlenden Versanddienstleister-Angaben.
6. Warenkorb leeren, abmelden, anmelden als derselbe Kunde und bestätigen, dass die Historie intakt ist.

Wenn der Checkout durchgängig funktioniert, haben Sie den größten Teil des Weges geschafft. Die meisten Modulkonflikte treten während des Checkouts auf, denn dort feuern die meisten Hooks, läuft das meiste JavaScript und werden die meisten AJAX-Endpunkte auf einer einzigen Seite angesprochen.

Phase 5: Performance: den Reiter „Netzwerk" öffnen

Manche Module verursachen echten Overhead. Wir haben Shops auditiert, in denen ein einziges „Social Proof"-Modul 1,4 Sekunden TTFB hinzugefügt hat, weil es einen synchronen externen API-Aufruf innerhalb von hookDisplayHeader ausführte. Genau die Art von Sache, die die Core Web Vitals ruiniert und sechs Wochen später in der Search Console auftaucht.

Drei schnelle Prüfungen, bevor Sie das Modul akzeptieren:

• Entwicklertools-Reiter „Netzwerk": welche neuen Anfragen fügt das Modul hinzu, und wie groß sind sie? Ein 300-KB-JS-Bundle auf jeder Seite ist nicht kostenlos.
• Serverseitiges Timing: installieren Sie es kurz mit aktiviertem Debug-Modus und schauen Sie sich den Reiter „Performance" der Symfony-Toolbar an. Modul-Hooks, die jeweils mehr als 50 ms benötigen, sind einen näheren Blick wert.
• Externe Aufrufe innerhalb von Hooks: durchsuchen Sie das Modul nach curl_exec, file_get_contents('http, fopen('http. Synchrone ausgehende Aufrufe aus einem Hook, der bei einem Seiten-Rendering feuert, sind ein sofortiges Warnsignal.

Modul-Updates testen

Updates sind in der Regel riskanter als Neuinstallationen. Bei Neuinstallationen kontrollieren Sie den Zeitpunkt. Updates können über Auto-Update oder über One-Click-Installationen aus dem Addons Marketplace eintreffen und Sie überraschen.

Lesen Sie das Änderungsprotokoll, bevor Sie auf Aktualisieren klicken. Wenn es Änderungen am Datenbankschema erwähnt, führen Sie das Upgrade zuerst auf Staging aus und prüfen Sie, ob upgrade/install-X.Y.Z.php tatsächlich ausgeführt wird. Unvollständige Upgrades sind die Ursache Nummer 1 für „Modul ist nach dem Update kaputt"-Tickets, die uns erreichen. Leeren Sie nach dem Update den Smarty-Cache und den Klassen-Index gemeinsam:

rm -rf var/cache/prod/*
rm -f var/cache/prod/class_index.php

Führen Sie dann die vollständige Phase-4-Regression durch. Der Instinkt „ich habe gerade aktualisiert, was kann da schon kaputtgehen" ist falsch. Einstellungen können verloren gehen, Standardkonfigurationen können überschrieben werden und Overrides können stillschweigend aufhören zu funktionieren, wenn sich die Signatur der übergeordneten Methode ändert.

Multi-Version-Tests: wie wir es tatsächlich machen

Für Entwickler, die Module über mehrere PS-Versionen hinweg ausliefern, ist die einzige ehrliche Antwort dedizierte Container pro Version. Wir betreiben vier Versionsstränge gleichzeitig:

Unser Release-Arbeitsablauf lässt das Modul durch alle vier laufen, bevor die ZIP freigegeben wird. Die Wahl des Containers ist entscheidend: Eine „PS-9-kompatibel"-Aussage von einem Anbieter, der nur auf 9.0 getestet hat, bedeutet so gut wie nichts. 9.1 Hat tiefgreifende Änderungen am Katalogbaum hinzugefügt und mehrere veraltete Hooks entfernt. Wir verwenden unseren Befehl certify, um die fertige ZIP auf veraltete API-Aufrufe zu durchsuchen, bevor sie nach releases/ gelangen darf.

Wenn auf Staging etwas schiefgeht

Das Back-Office ist nach der Installation nicht erreichbar

Keine Panik, und installieren Sie PrestaShop nicht neu. Verbinden Sie sich per SSH, benennen Sie das Modulverzeichnis um, damit es aus dem Weg ist, und leeren Sie den Cache:

mv modules/badmodule modules/badmodule_disabled
rm -rf var/cache/prod/* var/cache/dev/*

Das Back-Office sollte zurückkommen. Holen Sie sich nun den Fehler aus var/logs/ und senden Sie ihn an den Anbieter. Das sind die Daten, die er zur Behebung benötigt. Ein Anbieter, der den Fehler aus einer Log-Zeile nicht reproduzieren kann, hat keinen Dev-Shop, der zu Ihrer Version passt. Behandeln Sie das als Hinweis darauf, ob Sie ihn weiterhin nutzen sollten.

Weißbildschirm im Front-Office

Bearbeiten Sie config/defines.inc.php und schalten Sie _PS_MODE_DEV_ auf true um. Laden Sie neu. Sie erhalten den tatsächlichen Stack-Trace. Lesen Sie den Dateipfad im Trace, wenn er innerhalb des neuen Moduls liegt, ist das Ihr Übeltäter; wenn er im Core liegt, die Parameter aber falsch aussehen, betrachten Sie wahrscheinlich einen Fehler im Rückgabewert eines Hooks (Code eines Action-Hooks, der versehentlich auf einem Display-Hook registriert wurde, oder umgekehrt).

Schalten Sie den Dev-Modus in der Sekunde wieder auf false, in der Sie haben, was Sie brauchen. Live-Shops mit aktiviertem Dev-Modus legen Stack-Traces offen und werden auf PS 9 die DB-Zugangsdaten in Fehlerseiten preisgeben.

Zwei Module stehen im Konflikt

Die Bisektion ist langweilig, aber zuverlässig. Deaktivieren Sie beide. Aktivieren Sie A. Führen Sie die vollständige Regression aus Phase 4 aus. Aktivieren Sie B. Führen Sie Phase 4 erneut aus. Wenn es nur mit beiden aktiv kaputtgeht, betrachten Sie eines von drei Dingen: dieselbe Display-Hook-Position, die sich gegenseitig bekämpft, dieselbe Core-Klasse, die von beiden überschrieben wird, oder konkurrierende JS-Bibliotheken (unterschiedliche jQuery-Versionen oder zwei CSS-Frameworks, die beide .container für sich beanspruchen).

Override-Konflikte protokollieren eine Zeile, nach der Sie suchen können:

grep "is already overridden" var/logs/*.log

Die Lösung ist manuelles Zusammenführen. Öffnen Sie beide Override-Dateien, kombinieren Sie die Logik, installieren Sie das zweite Modul und löschen Sie var/cache/prod/class_index.php. Dokumentieren Sie, was Sie zusammengeführt haben. Beim nächsten Update eines der beiden Module müssen Sie es erneut zusammenführen.

Automatisierte Tests für Modulentwickler

Wenn Sie Module schreiben (nicht nur installieren), zahlt sich die Investition in Tests schnell aus. Hier ist, was wir tatsächlich ausführen.

PHPUnit für jede Klasse, deren Logik sich von PrestaShop trennen lässt. Tokenizer, Kalkulatoren, Formatierer, Scheduler. Mocken Sie die PrestaShop-Aufrufe an der Grenze; testen Sie die Geschäftslogik, ohne einen Shop hochzufahren. Wir führen diese bei jedem Commit über unseren ship-Arbeitsablauf aus, bevor die ZIP überhaupt erstellt wird.

Playwright für Front-Office-Smoke-Tests. In den Warenkorb legen, Checkout, Anmeldung. Die Art von Test, die „Ihr neues Release hat den Kaufen-Button zerstört" abfängt, bevor es ein Kunde tut. Wir halten diese unter insgesamt 30 Sekunden Laufzeit. Alles Langsamere wird nicht mehr ausgeführt.

GitHub Actions verdrahtet das Ganze. Schieben Sie einen Commit, und der Workflow fährt PS 1.7.8 und PS 9.1 in Containern hoch, installiert das Modul, führt PHPUnit aus, führt die Playwright-Suite aus und führt dann unseren Befehl certify auf der fertigen ZIP aus, um veraltete PrestaShop-API-Aufrufe zu markieren. Wenn irgendetwas rot aufleuchtet, wird die Release-ZIP nicht erzeugt.

Die Checkliste, die wir tatsächlich verwenden

An die Wand über unserem Dev-Rack gepinnt. Zwölf Punkte, der Reihe nach. Wir liefern kein Release aus, bis jede Zeile grün ist.

Jedes Modul von mypresta.rocks wird mit einer kostenlosen 30-Tage-Demo ausgeliefert, sodass Sie diese Checkliste auf Ihrem eigenen Staging durchgehen können, bevor Sie für irgendetwas bezahlen. Gehen Sie sie durch. Wenn etwas fehlschlägt, sagen Sie es uns. Genau das ist das Feedback, das das nächste Release besser macht.

Weiterführende Lektüre

• So erstellen Sie eine PrestaShop-Staging-Site: die Testumgebung, auf der dieser gesamte Arbeitsablauf beruht
• Unverzichtbare Werkzeuge für die PrestaShop-Entwicklung: was wir täglich zur Untersuchung von Modulen verwenden
• Lokale PrestaShop-Entwicklung: Einrichtung mit XAMPP, WAMP, Docker und Linux: lokale Container-Einrichtung, die unserer entspricht
• PrestaShop-Hooks und -Overrides: das Hook-System verstehen, auf das die meisten Modulfehler zurückgehen

Verwandte Module

• Performance Revolution: Performance-Regressionen vor dem Release abfangen
• MPR Checkout Revolution: den vollständigen Checkout-Pfad regressionstesten
• Issue Tracker: reproduzierbare Fehlerberichte aus dem Testen protokollieren

Passende Fragen

• Das Modul zeigt "This module requires PHP X.Y". Kann ich es trotzdem installieren?
• Ich habe das Modul hochgeladen, aber PrestaShop meldet „Unable to install module.“
• Kann Performance-Debugging beschränkt werden?
• Wie aktiviere ich den Debug-Modus in PrestaShop?
• Meine Modulkonfiguration wird nicht gespeichert.
• Das Modul zeigt den Fehler „Class not found“ oder „Namespace not found“.