Pagina 1 di 2
I test servono a poter modificare il codice senza paura. Una codebase continua a evolversi, invece di irrigidirsi, quando ha una suite di test di cui il team si fida. In questa categoria il testing è uno strumento economico di gestione del rischio, da usare con giudizio.
Spesso si parte dal legacy reale. Nelle aziende il punto di partenza è quasi sempre 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.
Poi si tratta di testare ciò che conta davvero. 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: un finto database in memoria 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 ti dice che non hai rotto il codice mentre lo cambiavi. Per lavorare tranquilli basta questo.
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:
