Cos'è il test di regressione visiva? Screenshot come asserzioni

Il test di regressione visiva scatta uno screenshot della tua interfaccia, lo confronta con uno approvato in precedenza e fallisce quando sono cambiati pixel che nessuno aveva accettato di cambiare. È l’unico tipo di test che coglie una modifica al foglio di stile che sposta un pulsante di quattro pixel a sinistra, perché quello non è un comportamento che una qualsiasi asserzione avrebbe mai descritto.

Tutto il resto discende da un fatto scomodo: uno screenshot non è deterministico, e un test che non è deterministico prima o poi verrà ignorato.

Cosa produce un’esecuzione

Tre immagini per controllo, e la terza è l’unica che qualcuno guarda.

• La baseline - lo screenshot approvato, versionato insieme al codice.
• La candidata - ciò che l’interfaccia rende adesso.
• Il diff - le due sovrapposte, con i pixel cambiati evidenziati.

Un controllo passa quando la candidata corrisponde alla baseline, e fallisce altrimenti. Fallire non è la stessa cosa che essere sbagliato: una riprogettazione voluta fa fallire ogni controllo che tocca, e la correzione consiste nell’approvare i nuovi screenshot come baseline. È in quel passaggio di approvazione che sta il lavoro vero.

I fallimenti che non sono fallimenti

Quasi tutto ciò che qui è difficile sono i falsi positivi, e arrivano da un elenco breve delle stesse cause.

• L’antialiasing e il rendering dei font. Lo stesso testo su due macchine, o con due driver grafici, non sono gli stessi pixel.
• Qualsiasi cosa mostri l’ora corrente. Un timestamp, un “3 giorni fa”, un anno di copyright.
• I dati dinamici. Un elenco ordinato per data, un nome estratto a caso da una fixture, un numero che cresce.
• Animazioni e transizioni. Uno screenshot scattato a metà di una transizione è un testa o croce.
• I font che arrivano tardi. Lo screenshot viene scattato prima che il webfont sia caricato, così la baseline ha un carattere e la candidata un altro.
• Le barre di scorrimento. Diverse da un sistema operativo all’altro, e spesso dentro l’area catturata.

Ognuna ha una correzione noiosa: congelare l’orologio, sostituire i dati con dati fissi, disattivare le animazioni, aspettare che i font si assestino ed eseguire ogni cattura in un unico ambiente controllato invece che sulla macchina che capita libera. Docker è la risposta abituale all’ultimo punto, ed è di gran lunga la maggiore fonte di rumore se lo salti.

Vale a dire che una suite visiva è un problema di test flaky con un altro cappello. Vale la stessa regola: un controllo che fallisce per ragioni estranee al codice smette di essere letto, e una suite che nessuno legge è peggio di nessuna suite, perché il tempo lo costa lo stesso.

Le soglie sono il primo istinto sbagliato

La risposta ovvia al rumore è consentire che una percentuale di pixel differisca. Funziona, ed è anche il modo in cui passa un difetto vero.

Debole

Fallire se differisce più dello 0,5 % dei pixel - che su una pagina grande è spazio più che sufficiente perché un pulsante si sposti, un prezzo cambi o l'etichetta di un campo sparisca

Meglio

Tolleranza zero, con regioni escluse per nome: l'orologio nell'intestazione, l'avatar, il grafico che si ridisegna. Ogni esclusione è una decisione che qualcuno ha messo per iscritto

Una soglia globale è una dichiarazione secondo cui una frazione ignota della tua interfaccia può cambiare senza dirtelo. Una regione ignorata è una dichiarazione su un elemento preciso, rivedibile in una pull request, e non cresce in silenzio man mano che la pagina si allarga.

Cosa non può dirti

Non può dirti che un cambiamento è sbagliato. Ti dice che un cambiamento c’è stato, e una persona decide quale delle due cose sia.

Sembra una distinzione da poco finché non conti le revisioni. Ogni cambiamento visivo voluto produce una coda di diff che qualcuno deve guardare e approvare, e se quella persona non ha un nome, nel giro di un mese la coda diventa un timbro automatico. A quel punto la suite gira, è verde ed è inutile.

Inoltre controlla soltanto ciò su cui l’hai puntata, nei browser e nelle dimensioni di finestra che le hai indicato. È questa la lacuna che vale la pena nominare, perché è lì che vivono i bug interessanti. Un layout che si rompe solo in Safari, o solo a 320 pixel di larghezza, o solo quando il browser non riesce a decodificare il video che stai servendo, è invisibile a una suite che cattura Chrome a un’unica dimensione.

Quando si ripaga

Lo schema è la ripetizione. Il test visivo rende dove gli stessi componenti vengono resi molte volte, in modi che una persona non può concretamente ricontrollare.

Un design system o una libreria di componenti è il caso più forte: una modifica al padding tocca tutto, e la suite ti dice esattamente cosa ha toccato. Le pagine di marketing sono il secondo, perché sono soprattutto layout e una rotta costa denaro in modo diretto. Tutto ciò che viene reso in più lingue o temi è il terzo - la stessa pagina in sette lingue sono sette occasioni perché una traduzione sia più lunga del suo contenitore, e nessuno le apre tutte e sette a mano a ogni rilascio.

Rende molto meno su un’interfaccia che viene ridisegnata ogni settimana, dove ogni esecuzione è un muro di approvazioni, e sulle schermate interne dove un difetto estetico costa a qualcuno un’alzata di spalle.

Dove si colloca accanto a tutto il resto

Il test di regressione visiva è test di regressione con uno screenshot come asserzione, quindi decide la stessa logica cosa ci sta dentro: cose che funzionavano e devono continuare a funzionare. Il tuo piano di test dovrebbe dire quali pagine sono coperte e, cosa più utile, quali no.

Non è nemmeno la stessa cosa della segnalazione visiva dei bug, nonostante la parola in comune, e le due rispondono a domande opposte. Una suite visiva trova un cambiamento non voluto prima che qualcuno lo veda, negli ambienti che hai scelto. Una segnalazione ti dice cosa è andato storto per una persona vera, nel browser che ha davvero, sulla pagina che stava davvero usando. Nessuna delle due sostituisce l’altra: la prima è una rete, la seconda è quello che fai del pesce che è passato.

Non vendiamo uno strumento di test visivo, e questo è il limite onesto di quello che possiamo dirti sul farne funzionare uno. Quello che vediamo noi è l’altro capo - la segnalazione che arriva perché qualcosa si è reso male per qualcuno, su un browser o una dimensione di schermo che nessuno aveva catturato.

Un punto di partenza che regge l’impatto

Cinque pagine, un browser, una dimensione di finestra, in esecuzione in CI su ogni pull request, in un container perché i pixel siano stabili. Una persona con un nome approva i diff. Regioni escluse invece di una percentuale.

Aggiungi browser e dimensioni quando le cinque pagine sono verdi e affidabili da un mese. La maggior parte delle suite che vengono abbandonate erano troppo ampie il primo giorno, e quelle che sopravvivono sono partite più piccole di quanto sembrasse serio.