LLM per generazione test automatici: da 5% a 70% di copertura su codebase PHP legacy
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
Ultima modifica:
Un e-commerce torinese con 47.000 righe di PHP 5.6 procedurale, 340 chiamate mysql_connect(), un hosting che aveva annunciato la rimozione di PHP 5.6 entro 60 giorni, e un titolare che non poteva permettersi downtime. In quattro settimane l'ho migrato a PHP 8.4 senza riscrivere l'applicazione: ecco il metodo, gli strumenti, le breaking changes reali e le decisioni che hanno fatto la differenza. 
Gestionale PHP 5.4 di un intermediario creditizio: 93.000 righe, dati di 11.000 clienti, password in MD5, zero cifratura, backup su disco USB. NIS2 e DORA imponevano adeguamento immediato. Da settembre a dicembre 2025 ho portato il sistema a PHP 8.4 con cifratura, audit trail, 2FA e documentazione che ha superato la verifica dell'auditor. 
Quando mi consegnano un progetto PHP legacy senza documentazione, la prima settimana è sempre la stessa: leggere codice, mappare dipendenze, identificare i punti critici. Ho automatizzato questa fase con un agente Claude che processa il codice in chunk, costruisce una mappa delle dipendenze e produce un report strutturato. 
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. 
Un gestionale PHP su VPS OVH, il freelance sparito da tre mesi, credenziali perse, nessun backup del codice e il certificato SSL in scadenza tra 8 giorni. Le prime 48 ore di un subentro d'emergenza: mappatura accessi, backup immediato, rotazione credenziali e stabilizzazione prima di qualsiasi modifica. 
Un gestionale PHP legacy dove gli errori si scoprivano dalle telefonate dei clienti: nessun log strutturato, nessun alert, MTTR medio di 4 ore. Ho introdotto Monolog con output JSON, metriche operative con cron e alert Telegram in 5 giorni - senza riscrivere una riga di codice applicativo. MTTR sceso a 22 minuti. 
Un gestionale PHP 7.0 ereditato da un freelance sparito: 43.000 righe di codice, nessuna documentazione, e il titolare che deve decidere se investire nella modernizzazione o riscrivere da zero. In 30 giorni ho prodotto un audit completo con PHPStan, Psalm, analisi delle dipendenze e una roadmap di intervento con costi e priorità. 
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. 
Un gestionale PHP 7.0 con 14 SQL injection, 23 punti XSS e un file phpinfo.php accessibile pubblicamente con tutte le credenziali visibili. L'audit che ho condotto in 3 giorni con grep, Psalm taint analysis e OWASP ZAP, e il piano di remediation che ha chiuso le 37 vulnerabilità critiche in due settimane.