Pagina 2 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 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
Queue::fake() verifica che un job venga dispatchato correttamente, ma non testa cosa succede dentro handle() quando il job deve rilasciarsi, cancellarsi o fallire. withFakeQueueInteractions(), introdotto in Laravel 11, permette di chiamare handle() in isolamento e asserire su release(), delete() e fail() senza un broker reale. Continua a leggere
L'HTTP Client di Laravel wrappa Guzzle aggiungendo macro riutilizzabili, retry con backoff esponenziale e Http::fake() per testing deterministico. In un applicativo con 12 integrazioni esterne, il refactoring da chiamate Guzzle sparse a service class con macro ha eliminato 400 righe di codice duplicato e reso testabili integrazioni che prima non lo erano. Continua a leggere
Tool gratuiti per costruire e verificare i tuoi test:
