Come testare correttamente i moduli PrestaShop

Perché testiamo ogni modulo su tutte le versioni di PrestaShop supportate prima della pubblicazione

Pubblichiamo 159 moduli da mypresta.rocks, e ognuno di essi viene fatto girare su PS 1.6, 1.7.6, 1.7.8, 8.x e 9.x su container di sviluppo dedicati prima che lo ZIP di rilascio lasci il nostro server. Non abbiamo iniziato così. All'inizio ci fidavamo del fatto che "testato su PS 1.7" volesse dire qualcosa. Poi abbiamo pubblicato un modulo che funzionava su 1.7.8 e mostrava una schermata bianca su 1.7.6 perché StockAvailable::getQuantityAvailableByProduct aveva cambiato firma all'interno della stessa versione minore. Quello fu il giorno in cui costruimmo il banco di prova multi-container.

Questa pagina descrive il flusso di lavoro che usiamo davvero, sia per i nostri rilasci, sia per i clienti che testano moduli di terze parti sui loro negozi. È orientato verso i test che individuano bug reali, non verso i test che sembrano accurati sulla carta.

Il bug più economico è quello che il Suo container di sviluppo individua alle 15. Quello più costoso è quello che un cliente segnala il venerdì sera su un negozio live. Ogni passaggio qui sotto esiste perché lo abbiamo pagato a caro prezzo.

Prima di installare: i tre controlli che contano

La maggior parte dei ticket "questo modulo mi ha rotto il negozio" che riceviamo si sarebbe potuta evitare leggendo prima tre cose. Nessuna di esse richiede più di cinque minuti.

Compatibilità esatta della versione, non la versione maggiore

"Compatibile con PrestaShop 1.7" non Le dice quasi nulla. Tra PS 1.7.0 e 1.7.8 ci sono cinque anni e diversi cambiamenti del core che rompono la compatibilità. Lo stesso vale per 8.0 e 8.2. Apra il file config.xml del modulo, oppure composer.json, e guardi ps_versions_compliancy:

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

Se il Suo negozio è al di sotto del minimo o al di sopra del massimo, l'installazione fallirà del tutto, o, peggio, si installerà e andrà in crash più tardi su un hook che il modulo dava per esistente.

Per la versione di PHP vale la stessa storia. Un modulo scritto per PHP 8.1+ che usa proprietà tipizzate e classi readonly andrà in fatal error su PHP 7.4 con un parse error prima ancora che PrestaShop venga caricato. Verifichi la versione di PHP del Suo negozio in Parametri Avanzati → Informazioni e la confronti con i requisiti del modulo.

Numero di override

Decomprima il modulo e guardi la directory override/. Se vede override/classes/Cart.php, override/controllers/front/OrderController.php, qualsiasi cosa lì dentro. Quello è il singolo indicatore più affidabile di conflitti con qualunque altra cosa abbia già installato. Due moduli non possono fare l'override dello stesso metodo. Il secondo a essere installato semplicemente fallisce.

I moduli basati su hook sono quasi sempre più sicuri di quelli basati su override. Se la descrizione del modulo dice "usa override" e Lei ha già un modulo di checkout, un modulo SEO, o qualsiasi cosa che tocchi Cart o Product, si aspetti dei problemi.

Quali hook usa davvero

Apra il file PHP principale del modulo e cerchi registerHook. L'elenco Le dice esattamente dove questo modulo andrà a inserirsi. Un "semplice modulo banner" che si registra su actionFrontControllerSetMedia, displayHeader, actionCartSave e actionValidateOrder non è un semplice modulo banner, sta facendo cose che dovrebbe conoscere prima di installarlo.

L'ambiente di staging deve corrispondere alla produzione

Un sito di staging "abbastanza simile" alla produzione non è staging. È un negozio diverso che per caso possiede anche Lei. Lo scopo è riprodurre le condizioni esatte che il modulo incontrerà sul sito live. Se il Suo staging gira su PHP 8.1 e la produzione su 7.4, i Suoi test non dimostrano nulla.

La nostra regola per lo staging dei clienti: stesso PHP, stesso PrestaShop, stesso tema, stessi moduli, stesso database (aggiornato negli ultimi sette giorni), stesso web server. Usiamo container Docker per ogni negozio proprio perché rendono tutto questo banale, `docker compose` avvia un ambiente identico in meno di un minuto. Consulti la nostra guida al sito di staging per la configurazione che usiamo.

Il flusso di lavoro di test

Fase 1: backup, anche su staging

Sì, anche su staging. Sta per dedicare 30 minuti ai test. Perdere il database a causa di un'installazione malriuscita significa ri-clonare la produzione, che è la parte lenta. Faccia prima un dump:

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

# Docker (come lo eseguiamo noi)
sudo docker exec <your-shop>-db mysqldump -u root -p'password' prestashop > ~/backup_before_module.sql

E già che c'è, faccia anche uno snapshot della directory modules/. Se l'installer del modulo lascia cadere file nelle directory di altri moduli (sì, lo abbiamo visto succedere), lo snapshot dei file è ciò che La salva.

Fase 2: installazione e osservazione dei log

Non si limiti a caricare e cliccare in giro. Tenga d'occhio var/logs/ mentre l'installer è in esecuzione:

tail -f var/logs/*.log

Se l'installer fallisce, vorrà l'errore vero, non un "installazione del modulo fallita" in rosso. Errori comuni che vediamo: estensioni PHP mancanti (intl, gd, curl), permessi insufficienti sui file in modules/, slug di ruolo duplicati in ps_authorization_role da una precedente installazione fallita. Quest'ultimo è il motivo per cui esiste il nostro script interno nuke-module.sh, pulisce a fondo ogni traccia di un modulo, così la successiva installazione parte da zero.

Fase 3: test funzionale: ciò che il modulo dichiara

Scorra l'elenco delle funzionalità del modulo, una voce alla volta. La pagina di configurazione si carica, le impostazioni persistono dopo il salvataggio, ogni funzionalità documentata fa davvero ciò che afferma. Verifichi la posizione nel menu del back office promessa dalla documentazione. Cambi la lingua del back office e controlli che esistano le traduzioni per quella usata dal Suo team.

Poi il front office: visiti ogni tipo di pagina che il modulo dovrebbe modificare. Apra gli Strumenti per sviluppatori, osservi la console per eventuali errori JavaScript, osservi la scheda Rete per richieste fallite e 404 sugli asset del modulo stesso. Un modulo che aggiunge views/css/style.css tramite tag <link> grezzi anziché registerStylesheet non riceverà il versionamento anti-cache. È un 404 pronto a scattare la prossima volta che svuoterà la cache.

Fase 4: test di regressione: cos'altro si è rotto

Questo è il passaggio che tutti saltano e individua più bug di tutte le altre fasi messe insieme. Il modulo funziona. Ora: tutto il resto funziona ancora?

I nostri moduli checkout-revolution e performance-revolution toccano abbastanza del carrello e della pipeline di rendering da farci avere uno script di regressione fisso per loro, sei percorsi che eseguiamo a ogni rilascio:

1. Aggiunta al carrello da una pagina prodotto, da una pagina di categoria e dai risultati di ricerca. Tre punti perché coinvolgono tre controller diversi.
2. Completamento di un checkout end-to-end con un metodo di pagamento reale, verificando che l'ordine compaia nell'amministrazione con i totali corretti.
3. Registrazione di un nuovo cliente con conferma dell'invio dell'email di benvenuto.
4. Ricerca di un prodotto per nome, per riferimento e per EAN.
5. Dettaglio ordine in amministrazione che si apre senza problemi, nessuna notice PHP, nessuna scheda rotta, nessuna informazione del corriere mancante.
6. Svuotamento del carrello, logout, login come lo stesso cliente, con conferma che la cronologia sia intatta.

Se il checkout funziona end-to-end, è già a buon punto. La maggior parte dei conflitti tra moduli emerge durante il checkout, perché è lì che scatta il maggior numero di hook, gira più JavaScript e vengono colpiti più endpoint AJAX su una singola pagina.

Fase 5: prestazioni: apra la scheda Rete

Alcuni moduli aggiungono un sovraccarico reale. Abbiamo verificato negozi in cui un singolo modulo di «prova sociale» aggiungeva 1,4 secondi di TTFB perché effettuava una chiamata API esterna sincrona dentro hookDisplayHeader. Il genere di cosa che rovina i Core Web Vitals e che si presenta in Search Console sei settimane dopo.

Tre controlli rapidi prima di accettare il modulo:

• Scheda Rete degli Strumenti per sviluppatori: quali nuove richieste aggiunge il modulo, e quanto sono grandi? Un bundle JS da 300KB su ogni pagina non è gratuito.
• Tempi lato server: installi brevemente con la modalità debug attiva e guardi la scheda "Prestazioni" della barra degli strumenti di Symfony. Gli hook del modulo che impiegano più di 50ms ciascuno meritano un esame più attento.
• Chiamate esterne dentro gli hook: cerchi con grep nel modulo curl_exec, file_get_contents('http, fopen('http. Una chiamata sincrona in uscita da qualsiasi hook che scatta durante il rendering di una pagina è un campanello d'allarme immediato.

Testare gli aggiornamenti dei moduli

Gli aggiornamenti sono di solito più rischiosi delle installazioni da zero. Le installazioni da zero le decide Lei come tempistica. Gli aggiornamenti possono arrivare tramite auto-aggiornamento o tramite installazioni con un clic dall'Addons Marketplace e coglierLa di sorpresa.

Legga il changelog prima di cliccare aggiorna. Se menziona modifiche allo schema del database, esegua l'aggiornamento prima su staging e controlli che upgrade/install-X.Y.Z.php venga effettivamente eseguito. Gli aggiornamenti incompleti sono la causa numero 1 dei ticket "il modulo si è rotto dopo l'aggiornamento" che riceviamo. Dopo l'aggiornamento, svuoti insieme la cache di Smarty e l'indice delle classi:

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

Poi esegua la regressione completa della Fase 4. L'istinto del "ho appena aggiornato, cosa mai potrebbe rompersi" è sbagliato. Le impostazioni possono andare perse, le configurazioni predefinite possono essere sovrascritte e gli override possono smettere silenziosamente di funzionare quando il metodo della classe genitore cambia firma.

Test multi-versione: come lo facciamo davvero

Per gli sviluppatori che pubblicano moduli su più versioni di PS, l'unica risposta onesta sono container dedicati per ogni versione. Eseguiamo quattro tracce di versione in parallelo:

Il nostro flusso di rilascio fa passare il modulo attraverso tutti e quattro prima che lo ZIP venga approvato. La scelta del container conta: una dichiarazione di "compatibile con PS 9" da parte di un fornitore che ha testato solo su 9.0 non significa quasi nulla. La 9.1 ha introdotto modifiche che rompono la compatibilità nell'albero del catalogo e ha rimosso diversi hook legacy. Usiamo il nostro comando certify per analizzare lo ZIP compilato alla ricerca di chiamate ad API deprecate prima di consentirne l'ingresso in releases/.

Quando qualcosa va storto su staging

Il back office è inaccessibile dopo l'installazione

Non vada nel panico e non reinstalli PrestaShop. Si colleghi in SSH, sposti via la directory del modulo e svuoti la cache:

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

Il back office dovrebbe tornare. Ora recuperi l'errore da var/logs/ e lo invii al fornitore. È il dato di cui ha bisogno per correggerlo. Un fornitore che non riesce a riprodurre l'errore da una riga di log è un fornitore che non ha un negozio di sviluppo corrispondente alla Sua versione. Lo consideri un'informazione utile per decidere se continuare ad affidarsi a lui.

Schermata bianca sul front office

Modifichi config/defines.inc.php e imposti _PS_MODE_DEV_ su true. Ricarichi. Otterrà lo tracce dello stack reale. Legga il percorso del file nel trace, se è all'interno del nuovo modulo, è quello il colpevole; se è nel core ma i parametri sembrano sbagliati, probabilmente si trova davanti a un bug nel valore di ritorno di un hook (codice di un action hook registrato per errore su un display hook, o viceversa).

Riporti la modalità di sviluppo su false nell'istante stesso in cui ha ciò che Le serve. I negozi in produzione con la modalità di sviluppo attiva espongono gli tracce dello stack e, su PS 9, faranno trapelare le credenziali del database nelle pagine di errore.

Due moduli in conflitto

La bisezione è noiosa ma affidabile. Disabiliti entrambi. Abiliti A. Esegua la regressione completa della Fase 4. Abiliti B. Esegua di nuovo la Fase 4. Se si rompe solo con entrambi attivi, si trova davanti a una di queste tre cose: stessa posizione di display hook che entra in conflitto, stessa classe del core sovrascritta da entrambi, oppure librerie JS in competizione (versioni diverse di jQuery o due framework CSS che reclamano entrambi .container).

I conflitti di override registrano una riga su cui può fare grep:

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

La soluzione è la fusione manuale. Apra entrambi i file di override, combini la logica, installi il secondo modulo, elimini var/cache/prod/class_index.php. Documenti ciò che ha unito, la prossima volta che uno dei due moduli si aggiorna, dovrà rifare la fusione.

Test automatizzati per gli sviluppatori di moduli

Se scrive moduli (non si limita a installarli), l'investimento nei test si ripaga in fretta. Ecco cosa eseguiamo davvero.

PHPUnit per qualsiasi classe che abbia una logica separabile da PrestaShop. Tokenizzatori, calcolatori, formattatori, scheduler. Faccia il mock delle chiamate a PrestaShop al confine; testi la logica di business senza avviare un negozio. Eseguiamo questi test a ogni commit tramite il nostro flusso ship, prima ancora che lo ZIP venga compilato.

Playwright per gli smoke test del front office. Aggiunta al carrello, checkout, login. Il genere di test che individua "il Suo nuovo rilascio ha rotto il pulsante di acquisto" prima che lo faccia un cliente. Li manteniamo sotto i 30 secondi di tempo di esecuzione totale, qualsiasi cosa più lenta smette di essere eseguita.

GitHub Actions a tenere tutto insieme. Si invia un commit, il flusso di lavoro avvia PS 1.7.8 e PS 9.1 in container, installa il modulo, esegue PHPUnit, esegue la suite Playwright e poi esegue il nostro comando certify sullo ZIP compilato per segnalare le chiamate ad API di PrestaShop deprecate. Se qualcosa si accende di rosso, lo ZIP di rilascio non viene generato.

La checklist che usiamo davvero

Appesa al muro sopra il nostro rack di sviluppo. Dodici voci, in ordine. Non pubblichiamo un rilascio finché ogni riga non è verde.

Ogni modulo di mypresta.rocks viene fornito con una demo gratuita di 30 giorni, così può eseguire questa checklist sul Suo staging prima di pagare qualsiasi cosa. La esegua. Se qualcosa fallisce, ce lo dica. È esattamente il tipo di feedback che rende migliore il rilascio successivo.

Letture correlate

• Come creare un sito di staging PrestaShop: l'ambiente di test da cui dipende tutto questo flusso di lavoro
• Strumenti essenziali per lo sviluppo su PrestaShop: ciò che usiamo ogni giorno per ispezionare i moduli
• Sviluppo locale di PrestaShop: configurazione con XAMPP, WAMP, Docker & Linux: configurazione locale dei container analoga alla nostra
• Hook e override di PrestaShop: capire il sistema di hook a cui risale la maggior parte dei bug dei moduli

Moduli correlati

• Performance Revolution: individui le regressioni di prestazioni prima del rilascio
• MPR Checkout Revolution: esegua il test di regressione sull'intero percorso di checkout
• Issue Tracker: registri segnalazioni di bug riproducibili a partire dai test

Domande correlate

• Il modulo mostra "This module requires PHP X.Y", posso comunque installarlo?
• Ho caricato il modulo, ma PrestaShop dice "Unable to install module."
• Il debugging delle performance può essere limitato?
• Come abilito la modalità debug in PrestaShop?
• La configurazione del mio modulo non viene salvata.
• Il modulo mostra errore "Class not found" o "Namespace not found".