Pagina 1 di 2
I test non servono a fare bella figura in code review: servono a poter modificare il codice senza paura. La differenza fra una codebase che si evolve e una che si irrigidisce è quasi sempre la presenza di una suite di test di cui il team si fida. In questa categoria il testing non è un dogma, è uno strumento economico di gestione del rischio.
Il primo tema è partire dal legacy reale. Il punto di partenza nelle PMI non è quasi mai un progetto nuovo: è una codebase in produzione con zero test, dove ogni modifica rompe qualcosa da un'altra parte. Scrivo di come si introducono i primi test senza bloccare lo sviluppo, di quali test danno il massimo valore per primi, e di come si porta la copertura da quasi zero a un livello che ti fa dormire, oggi anche con l'aiuto di un LLM in pipeline.
Il secondo tema è testare ciò che conta davvero, non ciò che è comodo. Pest con mutation testing e dataset per misurare se i test valgono qualcosa, testing dei job in coda oltre il semplice controllo che siano stati messi in coda, Testcontainers per verificare l'integrazione con database e servizi reali invece di un finto database in memoria che nasconde proprio i bug che contano.
Se vuoi introdurre i test in un progetto che non ne ha, vedi i miei progetti PHP senior o scrivimi.
Un test non ti dice che il codice è giusto. Ti dice che non l'hai rotto mentre lo cambiavi. È esattamente ciò che serve.
Un'API Laravel che doveva gestire 1.000 richieste al secondo durante il lancio di un prodotto. Ho costruito scenari k6 realistici basati sui log di produzione precedenti: mix di endpoint, distribuzione temporale, utenti concorrenti. Il test ha trovato un query N+1 che sarebbe diventato catastrofico sotto carico. Continua a leggere
Partire da 5% di copertura test su un codebase legacy è demoralizzante. Portarla al 70% in 3 mesi è realistico con LLM nell'anello di supporto - ma solo se il processo è strutturato. Ti mostro il workflow che ho testato: LLM genera characterization test sul comportamento esistente, sviluppatore verifica, itera. Con catalogo degli anti-pattern LLM tipici (test che passano sempre, assertion inutili) e come rilevarli. Continua a leggere
Un refactoring CSS su un gestionale Laravel aveva rotto la visualizzazione di 12 componenti - nessuno se ne era accorto fino alle segnalazioni degli utenti. Con Playwright ho implementato test di regressione visuale: ogni PR che modifica CSS viene confrontata con screenshot di riferimento. I bug visivi vengono intercettati in CI. Continua a leggere
Un'applicazione Laravel con la logica di business nei controller e le chiamate al database direttamente nei Model è impossibile da testare correttamente. Ho refactorizzato un gestionale HR verso l'architettura esagonale: il dominio ora è testabile senza database, e cambiare da MySQL a PostgreSQL ha richiesto un solo adapter. Continua a leggere
I test con SQLite in memoria non trovano i bug che nascono dalle differenze tra SQLite e MySQL. Con Testcontainers per PHP, ogni test di integrazione ottiene un'istanza MySQL reale in un container Docker, azzerata tra le esecuzioni. Ho adottato questo approccio per un cliente e-commerce: i bug in staging sono scesi del 60%. Continua a leggere
Un e-commerce Laravel con zero test e 40.000 righe di codice. Ho usato Claude API in una pipeline semi-automatizzata: input una classe PHP, output i test unitari e di integrazione. Con supervisione umana sulle asserzioni, ho portato la copertura dal 3% al 68% in tre settimane. Vediamo come. Continua a leggere
Un gestionale PHP legacy con zero test e 3 regressioni al mese: ogni fix rompeva qualcosa. In 5 giorni ho introdotto 28 smoke test HTTP e 12 snapshot test sulle funzioni di calcolo - senza toccare il codice applicativo. Regressioni in produzione scese da 3/mese a zero nel primo trimestre. Continua a leggere
Un gestionale PHP 5.6 con 23.000 righe, zero test e debito tecnico che rendeva ogni modifica un rischio: il cliente pagava il triplo per ogni nuova funzionalità rispetto a un'applicazione moderna. In tre mesi di refactoring incrementale con Strangler Fig Pattern, PHPStan e Rector l'ho reso manutenibile senza riscrivere una riga da zero. Continua a leggere
Un gestionale PHP legacy con 23.000 righe e zero test: ogni modifica rompeva qualcosa in un altro punto dell'applicazione. Ho introdotto characterization test con PHPUnit in una settimana - senza riscrivere una riga di codice applicativo - e il tasso di bug in produzione è sceso del 70% nel primo mese. Continua a leggere
Pest 3 ha portato mutation testing, dataset, arch presets e nested describe nel testing PHP. Per le PMI con API Laravel in produzione il problema non è più scrivere test, è scriverli in modo che individuino bug reali e girino in CI in tempi accettabili. Cosa testare, come strutturare la suite e come portarla in pipeline CI. Continua a leggere
Tool gratuiti per costruire e verificare i tuoi test:
