Come testare correttamente i moduli PrestaShop
Workflow pratico per testare i moduli PrestaShop — controlli preliminari, test funzionali, test di regressione e checklist stampabile.
Perché testare correttamente i moduli è importante
Installare un nuovo modulo PrestaShop sul vostro negozio in produzione senza testarlo è come cambiare il motore dell’auto mentre state guidando. Potrebbe funzionare — ma se non funziona, vi ritrovate bloccati nel traffico con clienti arrabbiati alle vostre spalle.
Conflitti tra moduli, incompatibilità con il tema ed effetti collaterali imprevisti sono le cause più comuni di disservizio del negozio. Quasi tutti sono prevenibili con un flusso di lavoro di test di base. Questa guida vi mostra come fare.
Il tempo che investite nei test è sempre inferiore al tempo che spendete per riparare un negozio in produzione non funzionante. Un test di 15 minuti su staging può farvi risparmiare ore di risoluzione problemi d’emergenza.
Prima dell’installazione: controlli preliminari
Prima ancora di scaricare un modulo, verificate queste cose:
1. Matrice di compatibilità
Ogni fornitore di moduli affidabile elenca quali versioni di PrestaShop sono supportate dal modulo. Verificate che la vostra versione esatta sia coperta — non solo la versione principale. Un modulo che dice “PS 1.7” potrebbe non funzionare su PS 1.7.6 se è stato sviluppato per la 1.7.8.
Controllate anche la compatibilità PHP. Se il modulo richiede PHP 8.1+ e il vostro server esegue PHP 7.4, non funzionerà indipendentemente dalla versione di PrestaShop.
2. Indicatori di qualità del modulo
Cercate segnali che il modulo sia ben mantenuto:
- Aggiornamenti recenti: Quando è stata rilasciata l’ultima versione? Un modulo aggiornato l’ultima volta 3 anni fa è un segnale d’allarme.
- Supporto multi-versione: Il fornitore supporta attivamente più versioni di PrestaShop? Questo dimostra che comprende l’ecosistema.
- Documentazione: Esiste una guida utente o un manuale di installazione? Una buona documentazione è correlata a una buona qualità del codice.
- Politica di supporto: Cosa succede quando qualcosa va storto? C’è supporto via email, un sistema di ticket o solo un forum della comunità?
3. Conflitti con moduli esistenti
Alcune categorie di moduli sono note per i conflitti:
- Moduli checkout — più moduli agganciati al processo di checkout possono interferire tra loro
- Moduli SEO — i moduli di riscrittura URL possono entrare in conflitto tra loro e con il routing del core di PrestaShop
- Moduli che alterano il tema — i moduli che iniettano HTML/CSS personalizzato possono rompere il layout del tema
- Moduli con molti override — i moduli che fanno override delle classi core possono entrare in conflitto con altri override
Se avete già moduli nella stessa categoria, siate particolarmente cauti e testate in modo approfondito.
Configurare il vostro ambiente di test
Avete bisogno di un sito staging — una copia del vostro negozio in produzione dove potete testare in sicurezza. Se non ne avete ancora uno, leggete prima la nostra guida alla configurazione di un sito staging PrestaShop.
Il vostro sito staging dovrebbe essere:
- Una copia recente del vostro database e dei file di produzione (aggiornata nell’ultima settimana)
- Con la stessa versione PHP della produzione
- Con la stessa versione PrestaShop della produzione
- Con lo stesso tema della produzione
- Con gli stessi moduli installati della produzione
Questo è fondamentale — un sito staging che non corrisponde alla produzione è inutile per i test. L’obiettivo è simulare esattamente ciò che accadrà quando installerete il modulo sul vostro negozio reale.
Il flusso di lavoro per i test
Fase 1: Backup
Anche su staging, fate un backup prima di installare qualsiasi cosa. Questo vi permette di ripristinare velocemente se qualcosa va terribilmente storto.
# Quick database backup
mysqldump -u root -p prestashop > ~/backup_before_module.sql
Se utilizzate Docker:
docker exec staging-shop-db mysqldump -u root -p'password' prestashop > ~/backup_before_module.sql
Fase 2: Installare il modulo
- Caricate il file ZIP del modulo sul Back Office del vostro sito staging → Moduli → Carica
- Fate attenzione a eventuali errori di installazione — se l’installazione fallisce, non procedete
- Annotate il numero di versione del modulo come riferimento
Se il modulo non riesce a installarsi, controllate:
- I log degli errori PHP (
var/logs/o il log degli errori PHP del vostro server) - Se il modulo richiede estensioni PHP specifiche (GD, cURL, intl, ecc.)
- Se i permessi dei file sono corretti (la directory
modules/deve essere scrivibile)
Fase 3: Test funzionale
Ora testate tutto ciò che il modulo dichiara di fare. Esaminate la lista delle funzionalità del modulo in modo sistematico:
Test del Back Office
- Riuscite ad accedere alla pagina di configurazione del modulo?
- Tutte le impostazioni vengono salvate correttamente?
- Il modulo appare nella posizione di menu prevista?
- Le traduzioni funzionano (se applicabile)?
- Le nuove pagine di amministrazione si caricano senza errori?
Test del Front Office
- Visitate ogni tipo di pagina dove il modulo dovrebbe apparire (homepage, categoria, prodotto, carrello, checkout)
- Testate sia su desktop che su mobile — i problemi di responsività sono comuni
- Verificate che gli elementi visivi del modulo si integrino con il vostro tema
- Testate tutti gli elementi interattivi (pulsanti, moduli, filtri, popup)
- Controllate la console JavaScript per eventuali errori (premete F12 nel browser)
Fase 4: Test di regressione
Questo è il passaggio che la maggior parte delle persone salta — ed è il più importante. Un modulo potrebbe funzionare perfettamente da solo ma rompere qualcos’altro.
Testate questi percorsi critici anche se il modulo non ha nulla a che fare con essi:
- Flusso aggiungi al carrello: Aggiungete un prodotto al carrello dalla pagina prodotto, dalla pagina categoria e dai risultati di ricerca
- Checkout completo: Seguite l’intero processo di checkout — indirizzo, spedizione, pagamento — e verificate che l’ordine venga completato con successo
- Registrazione cliente: Create un nuovo account e verificate di poter effettuare il login
- Ricerca: Cercate un prodotto e verificate che i risultati appaiano correttamente
- Navigazione categorie: Navigate attraverso l’albero delle categorie principali
- Ordini in amministrazione: Verificate che gli ordini esistenti vengano ancora visualizzati correttamente nel Back Office
Se il checkout funziona, probabilmente va tutto bene. La maggior parte dei conflitti tra moduli emerge durante il checkout perché è la parte più complessa di PrestaShop — decine di hook, chiamate AJAX e dipendenze JavaScript convergono tutte su una singola pagina.
Fase 5: Controllo delle prestazioni
Alcuni moduli aggiungono un sovraccarico significativo — caricando JavaScript aggiuntivo, effettuando chiamate API o eseguendo query di database pesanti su ogni pagina.
- Aprite la scheda Network del vostro browser (F12 → Network) e controllate se il modulo aggiunge file JS/CSS di grandi dimensioni
- Confrontate i tempi di caricamento delle pagine prima e dopo l’installazione del modulo usando PageSpeed Insights o la scheda Performance del vostro browser
- Controllate se il modulo effettua chiamate API esterne ad ogni caricamento della pagina (possono aggiungere 200-500ms di latenza)
Un modulo ben costruito dovrebbe aggiungere un sovraccarico minimo. Se un singolo modulo aggiunge più di 200ms al tempo di caricamento della vostra pagina, vale la pena indagare.
Testare gli aggiornamenti dei moduli
Aggiornare un modulo esistente richiede lo stesso flusso di lavoro di test di una nuova installazione — a volte anche di più, perché gli aggiornamenti possono modificare comportamenti che avete già configurato.
Prima dell’aggiornamento
- Leggete attentamente il changelog — cosa è cambiato? Ci sono modifiche che rompono la compatibilità?
- Verificate se l’aggiornamento richiede un percorso di aggiornamento specifico (ad esempio, “bisogna aggiornare alla 2.x prima della 3.x”)
- Fate il backup della cartella del modulo attuale e della configurazione
Dopo l’aggiornamento
- Verificate che tutte le impostazioni esistenti siano state preservate
- Testate tutte le funzionalità elencate come “modificate” o “migliorate” nel changelog
- Eseguite la checklist completa dei test di regressione (Fase 4)
- Svuotate la cache di PrestaShop e controllate eventuali errori di compilazione Smarty/template
Testare su più versioni di PrestaShop
Se siete sviluppatori di moduli o gestite più negozi su diverse versioni di PrestaShop, dovete testare su tutte. La configurazione più pratica prevede container Docker, uno per versione:
| Container | Versione PS | Versione PHP | Scopo |
|---|---|---|---|
| ps-test-176 | 1.7.6 | 7.2 | Supporto legacy |
| ps-test-178 | 1.7.8 | 7.4 | Versione 1.7 più diffusa |
| ps-test-81 | 8.1 | 8.1 | PS 8 iniziale |
| ps-test-82 | 8.2 | 8.2 | PS 8 attuale |
| ps-test-91 | 9.1 | 8.3 | PS 9 più recente |
Questo è esattamente l’approccio che utilizziamo su mypresta.rocks — ogni modulo viene testato su tutte le versioni di PrestaShop supportate prima del rilascio. È l’unico modo per garantire la compatibilità tra le versioni.
Cosa fare quando qualcosa va storto
Il modulo si blocca durante l’installazione
Se un modulo si blocca durante l’installazione e rende inaccessibile il vostro Back Office:
- Accedete al vostro server tramite SSH o FTP
- Rinominate la directory del modulo:
mv modules/modulename modules/modulename_disabled - Svuotate la cache:
rm -rf var/cache/* - Il vostro Back Office dovrebbe essere nuovamente accessibile
- Contattate il fornitore del modulo con i dettagli dell’errore da
var/logs/
Il modulo causa una schermata bianca
Attivate la modalità debug per vedere l’errore effettivo:
- Modificate
config/defines.inc.php - Cambiate
define('_PS_MODE_DEV_', false);indefine('_PS_MODE_DEV_', true); - Ricaricate la pagina — dovreste vedere il messaggio di errore completo
- Ricordatevi di reimpostarlo su
falsedopo il debug
Conflitto tra moduli
Se due moduli sono in conflitto, il processo di debug è:
- Disattivate entrambi i moduli
- Attivate il primo modulo — testate
- Attivate il secondo modulo — testate di nuovo
- Se il conflitto appare solo quando entrambi sono attivi, verificate se:
- Si agganciano alla stessa posizione (comune con gli hook di visualizzazione)
- Fanno override della stessa classe core
- Caricano librerie JavaScript in conflitto (ad esempio, versioni diverse di jQuery)
- Segnalate il conflitto a entrambi i fornitori — gli sviluppatori responsabili lavoreranno insieme per risolverlo
Test automatizzati per gli sviluppatori
Se siete sviluppatori di moduli, considerate l’aggiunta di test automatizzati al vostro flusso di lavoro:
PHPUnit per la logica backend
Testate le classi PHP del vostro modulo indipendentemente da PrestaShop. Questo intercetta gli errori logici prima che raggiungano un negozio reale.
Playwright o Cypress per il frontend
I test automatizzati del browser possono verificare che l’interfaccia utente del vostro modulo funzioni correttamente in diversi scenari. Particolarmente utili per i moduli checkout dove il test manuale è noioso.
GitHub Actions per CI/CD
Eseguite la vostra suite di test automaticamente ad ogni commit. Questo impedisce alle regressioni di raggiungere le vostre build di rilascio.
Una semplice checklist per i test
Stampatela e usatela ogni volta che installate o aggiornate un modulo:
| Passo | Controllo | Stato |
|---|---|---|
| 1 | Il sito staging è una copia aggiornata della produzione | □ |
| 2 | Backup del database effettuato prima dell’installazione | □ |
| 3 | Modulo installato senza errori | □ |
| 4 | La pagina di configurazione del modulo funziona | □ |
| 5 | Le funzionalità del modulo funzionano come documentato | □ |
| 6 | Nessun errore nella console JavaScript | □ |
| 7 | Aggiungi al carrello funziona su tutti i tipi di pagina | □ |
| 8 | Il checkout completo si conclude con successo | □ |
| 9 | Registrazione/login del cliente funziona | □ |
| 10 | La ricerca restituisce risultati corretti | □ |
| 11 | Responsivo su mobile — nessun problema di layout | □ |
| 12 | Il tempo di caricamento della pagina non è significativamente impattato | □ |
Riepilogo
Testare i moduli non è complicato — è solo un’abitudine. Il flusso di lavoro è: backup → installazione su staging → test delle funzionalità → test di tutto il resto → controllo prestazioni → deploy in produzione. Ogni volta, senza eccezioni.
I proprietari di negozi che non hanno mai tempi di inattività d’emergenza non sono fortunati — semplicemente testano prima di fare il deploy. Potete essere uno di loro.
Tutti i moduli di mypresta.rocks includono una demo gratuita di 30 giorni in modo che possiate testare sul vostro sito staging prima dell’acquisto. Crediamo nel principio testa-prima-compra-dopo — perché non dovreste fidarvi solo della nostra parola.
More guides available
Browse our knowledge base for more practical PrestaShop tutorials, or reach out if you need help.