Concetti di test di regressione visiva

Il visual regression testing (VRT) rileva automaticamente le modifiche visive indesiderate tra diverse versioni del codice confrontando screenshot renderizzati pixel per pixel. Individua regressioni CSS — spostamenti del layout, cambiamenti di colore e spaziatura errata — che i test unitari non rilevano affatto.

Il VRT acquisisce screenshot di riferimento di componenti o pagine, quindi acquisisce nuovi screenshot dopo le modifiche al codice e li confronta. Le differenze vengono evidenziate in un'immagine diff. Gli sviluppatori esaminano i diff e approvano le modifiche intenzionali oppure correggono le regressioni involontarie.

Il confronto pixel per pixel mette a confronto le immagini pixel per pixel: è sensibile, ma tende a produrre falsi positivi dovuti all'antialiasing e alle differenze nel rendering dei subpixel. Gli strumenti di confronto strutturale (Applitools AI) confrontano l'intento visivo anziché i pixel esatti, riducendo i falsi positivi dovuti alle variazioni nel rendering dei font.

Gli screenshot approvati diventano la nuova baseline. Memorizzi le baseline nel controllo versione (Git LFS per le immagini di grandi dimensioni) o in un servizio cloud dedicato. Ogni PR mostra i diff rispetto alla baseline e i responsabili della manutenzione approvano o rifiutano le modifiche visive durante la revisione.

I test VRT a livello di componente verificano singoli componenti dell'interfaccia in isolamento (tramite Storybook). I test VRT a livello di pagina verificano pagine complete in un browser reale. I test dei componenti sono più rapidi e mirati; i test delle pagine rilevano i problemi di layout a livello di integrazione tra i componenti.

Verifichi tutti gli stati visivi: predefinito, hover, focus, attivo, disabilitato, caricamento, errore, vuoto e completo. Gli stati hover richiedono una simulazione JavaScript (page.hover() in Playwright). Una copertura incompleta degli stati crea punti ciechi per le regressioni negli stati interattivi.

Esegua il rendering degli screenshot in più browser (Chrome, Firefox, Safari) e viewport (mobile, tablet, desktop). Le differenze di rendering tra browser possono causare falsi positivi: utilizzi baseline specifiche per browser e configuri soglie di confronto che tollerino le variazioni di rendering note.

Il rendering dei font presenta differenze sottili tra combinazioni di sistema operativo, browser e GPU. Utilizzi ambienti CI coerenti (Docker + una versione specifica di Chrome) per eliminare i falsi positivi causati dall'ambiente. I servizi VRT cloud gestiscono automaticamente la coerenza dell'ambiente.

I contenuti dinamici — timestamp, avatar degli utenti, annunci e dati casuali — causano falsi positivi. Mascheri le regioni dinamiche con una sovrapposizione a tinta unita prima di acquisire lo screenshot. La maggior parte degli strumenti VRT supporta selettori di elementi per il mascheramento.

Esegua il VRT in CI per ogni PR. Interrompa la build quando vengono rilevati diff visivi non approvati. Assegni l'analisi dei diff visivi ai responsabili del design, non solo al team di sviluppo: le modifiche visive riguardano il design tanto quanto lo sviluppo.

Il VRT offre il maggiore ritorno sull'investimento nelle librerie di componenti e nei design system, dove la coerenza visiva è una funzionalità del prodotto. Per le pagine di marketing che cambiano frequentemente, il costo della manutenzione delle baseline può superare il valore del rilevamento delle regressioni.

Perché i test di regressione visiva producono falsi positivi a causa delle differenze nel rendering dei font?

I test di regressione visiva rilevano regressioni di CSS e layout confrontando screenshot tra diverse versioni del codice. Un VRT efficace richiede ambienti coerenti, copertura degli stati, mascheramento dei contenuti dinamici e un flusso di revisione che indirizzi le differenze ai revisori del design, trasformandolo in uno strumento collaborativo per la qualità, non solo in un gate automatizzato.