Generare test dai design Figma prima che esista il codice
Generate test dai design Figma prima che esista il codice: sviluppo guidato dai test per l'interfaccia, QA del design senza selettori e controlli che seguono il design.
10 min di letturaDal team di GUI Test Studio
Perché generare test dai design Figma?
I vostri designer hanno già scritto la specifica più precisa che il vostro team possieda.Un file Figma dice cosa deve mostrare ogni schermata: le parole su ogni pulsante, le icone, l'ordine dei campi, la schermata che arriva dopo un clic.Eppure la maggior parte dei team scrive i propri test end-to-end settimane dopo, a partire dall'app finita, e nel frattempo controlla il design a occhio.
Lo sviluppo guidato dal design ribalta quell'ordine.È lo sviluppo guidato dai test in cui il design, non il codice, è la specifica da cui nasce il primo test.Generate i test dai design Figma il giorno stesso in cui il design viene approvato.Il test fallisce finché la funzionalità non esiste.Viene superato il giorno in cui la build corrisponde al design.Da quel momento, tiene la build sotto controllo ogni volta che il design o il codice cambiano.
Questo articolo spiega lo sviluppo guidato dai test, perché i test end-to-end in codice non possono essere scritti per primi, cosa sono la QA del design e la deriva del design, e come GUI Test Studio, una suite di test end-to-end per app desktop e app web, trasforma un design Figma in un test eseguibile.
TDD, ATDD e BDD in un minuto
Sono tutti e tre modi di scrivere prima il test.Si differenziano per ciò da cui il test viene scritto e per chi lo legge.
| Pratica | Il test viene scritto a partire da | Chi lo legge |
|---|---|---|
| Sviluppo guidato dai test (TDD) | Un piccolo comportamento che il codice deve avere | Sviluppatori |
| Sviluppo guidato dai test di accettazione (ATDD) | I criteri di accettazione concordati dal team con il business | Tutto il team |
| Sviluppo guidato dal comportamento (BDD) | Scenari in parole semplici, spesso scritti come Given, When, Then con uno strumento come Cucumber | Tutto il team |
Il ciclo del TDD ha tre tempi.Rosso: scrivete un test che fallisce, perché il comportamento non c'è ancora.Verde: scrivete appena il codice necessario per farlo passare.Refactoring: migliorate il codice mentre il test lo mantiene corretto.
Anticipare così i test si chiama spesso shift-left testing.Un bug trovato prima che una funzionalità venga rilasciata costa meno da correggere.Un test scritto per primo è anche una specifica che nessuno può fraintendere.
Perché non si può scrivere un test end-to-end prima del codice?
Il TDD funziona bene per funzioni e API.All'interfaccia utente, di solito si ferma.Il motivo è il modo in cui i test end-to-end in codice trovano le cose sullo schermo.
Un test Selenium, Playwright o Cypress trova ogni elemento tramite un locator: un id, un selettore CSS, un XPath, un ruolo e un nome.Selenium documenta otto strategie di localizzazione, dall'id all'XPath.Cypress raccomanda un attributo dedicato, come data-cy, su ogni elemento che un test tocca.
Ognuno di questi è un fatto che riguarda il codice.Prima che il codice esista, non c'è alcun id da selezionare né alcun attributo a cui puntare.I page object, le classi che avvolgono ogni schermata per i test, vengono scritti su quello stesso markup.
Anche gli snapshot visivi in codice partono dalla build.Playwright crea i suoi screenshot di riferimento alla prima esecuzione, quindi l'immagine con cui un test confronta è l'app così com'è stata realizzata, non come è stata progettata.Storybook con Chromatic confronta ogni story di un componente con la sua baseline approvata, il che individua le modifiche tra una build e l'altra.
Così, in pratica, il test end-to-end viene scritto dopo la funzionalità, da qualcuno che guarda l'app finita.Controlla poi che l'app continui a fare ciò che fa oggi, che sia o meno ciò che era stato progettato.
QA del design e deriva del design
La QA del design è il controllo che la build corrisponda al design.Nella maggior parte dei team si fa a occhio dopo il passaggio di consegne del design: un designer mette il frame Figma accanto all'app in staging ed elenca ciò che differisce.
La deriva del design è lo scarto che cresce tra il design e il prodotto quando nessuno controlla.Un'etichetta riceve nuove parole nel codice.Lo spessore di un carattere non è quello del design system.Un'icona manca su una schermata.Ogni modifica è piccola, e insieme fanno sembrare il prodotto incompiuto.
Il test di regressione visiva da solo non colma quello scarto.Confronta la build di oggi con una build precedente, quindi una schermata che non ha mai corrisposto al suo design viene superata ogni volta.
Diversi strumenti passano già da Figma ai casi di test.L'IA generativa di Testsigma scrive scenari e casi di test dai frame Figma, una volta configurati un id del team Figma e un token di accesso.BrowserStack Test Companion legge un link Figma incollato e scrive casi di test, o script di automazione nel vostro framework.Applitools Eyes permette a un test automatizzato di usare un frame Figma come baseline visiva.
I casi di test scritti sono un vero aiuto per la pianificazione, ma una persona deve comunque eseguirli o trasformarli in codice.Uno script generato, come ogni test visivo in codice, raggiunge comunque ogni elemento tramite un locator che esiste solo una volta realizzata la funzionalità.Per uno sguardo più ampio sugli strumenti end-to-end, vedete lo studio comparativo.
Come si generano test end-to-end da un design Figma?
Un test può essere scritto da un design solo se non ha bisogno del codice.Deve trovare ogni elemento come fa una persona: da come appare e da ciò che dice.
È così che GUI Test Studio controlla una schermata.Un'asserzione visiva trova un elemento a vista e lo confronta con l'immagine che vi aspettate.Un'asserzione testuale legge le parole sullo schermo.Un design contiene già ogni immagine e ogni parola di cui quei controlli hanno bisogno.
| Cosa contiene il design Figma | Cosa riceve il test |
|---|---|
| Ogni schermata | Un'immagine di riferimento della schermata |
| Le parole di un'etichetta, di un titolo o di un pulsante | Un'asserzione testuale che attende quelle parole |
| Un valore che cambia, come una data o un importo | Un'asserzione testuale dinamica che attende un valore dello stesso tipo |
| Un'icona, un logo o un'immagine | Un'asserzione visiva che cerca quell'immagine |
| Le sezioni di una schermata, come la sua intestazione o il suo modulo | Un'asserzione di gruppo per sezione, che può controllare anche la disposizione |
| I collegamenti di un flusso del prototipo | I clic che portano da una schermata alla successiva |
Design
Le schermate Figma approvate
Rosso
Il test fallisce: la funzionalità non c'è ancora
Sviluppo
Uno sviluppatore o un agente di programmazione basato su IA scrive la funzionalità
Verde
La build corrisponde al design
Sviluppo guidato dai test per l'interfaccia, passo dopo passo
- 1
Generare il test dal design approvato
Il giorno in cui il design viene approvato, importatelo.Il test ora descrive la schermata così come è stata progettata, prima che qualcuno scriva la funzionalità.
- 2
Vederlo fallire: è il passo rosso
Eseguitelo sull'app di oggi.La nuova schermata non c'è, quindi i suoi controlli falliscono.Il rosso è proprio lo scopo: il test è l'elenco del lavoro ancora da fare.
- 3
Sviluppare finché non diventa verde
Uno sviluppatore, o un agente di programmazione basato su IA, realizza la funzionalità.La vostra pipeline esegue il test a ogni build con gtr-cli.Il report di affidabilità dice, elemento per elemento, cosa corrisponde già al design e cosa no.
- 4
Accettare una volta l'aspetto reale
Un design e una schermata reale raramente coincidono al pixel, perché i caratteri vengono resi in modo leggermente diverso.Dopo la prima esecuzione reale, accettate una volta l'aspetto effettivo dal report di affidabilità.Da quel momento, il test confronta con ciò che è reale.Vedete Quando l'app cambia di proposito.
- 5
Fare refactoring con il test a fare da guardia
Rinnovate lo stile dell'app, fatene il refactoring, cambiatene il framework.Il test non legge il vostro codice, quindi continua a essere superato finché la schermata resta corretta.Fallisce quando un utente vedrebbe una differenza.
Importa da Figma: il test prima della funzionalità
GUI Test Studio fa tutto questo con Importa da Figma.Un piccolo plugin gira all'interno di Figma e salva il vostro design in un unico file, un pacchetto di design.GUI Test Studio raccoglie quel file.Non c'è alcun account Figma da collegare né alcun token di accesso da creare, e nulla viene inviato da nessuna parte.
Il plugin viene installato insieme a GUI Test Studio.Lo aggiungete una volta sola nell'app desktop di Figma, in Plugins, Development, Import plugin from manifest....
In GUI Test Studio, scegliete File, Importa da Figma...: la finestra attende il vostro design.In Figma, avviate il plugin e selezionate le schermate che volete, oppure scegliete un flusso del prototipo.Le sue schermate arrivano allora in ordine, con i clic che portano dall'una alla successiva.Lasciate il file esportato nella vostra cartella Download: GUI Test Studio tiene d'occhio quella cartella e apre il design entro un secondo o due.
La revisione mostra ogni schermata con un riquadro attorno a ogni elemento, e dice quale controllo riceve ciascuno.Un testo viene controllato come testo solo quando si legge davvero sull'immagine.Le parole troppo piccole o troppo tenui ricevono invece un controllo come immagine, e l'elenco dice perché.I paragrafi lunghi e le foto grandi sono elencati ma non selezionati, perché di solito sono contenuto di esempio.
Fate clic su Importa, e tutto arriva come un unico scenario con il nome del vostro design.Ogni schermata diventa un'immagine sulla traccia Riferimento visivo.I suoi controlli vanno sulla traccia Asserzioni, raggruppati per sezione.Per un flusso del prototipo, il clic che porta alla schermata successiva è diretto sul pulsante da cui parte il collegamento del design.
Un design non dice dove si troverà la finestra dell'app, quindi questi controlli cercano in tutto lo schermo.Confrontano con un rigore permissivo, così le piccole differenze di resa tra un design e una schermata reale sono tollerate, mentre un elemento mancante o una parola cambiata fanno comunque fallire il controllo.
Il vostro designer termina il flusso “Sign in”: Login, poi Dashboard, poi Settings.Importate il flusso e ottenete tre immagini, il clic su Sign in, il clic sull'ingranaggio delle impostazioni, e i controlli di ogni schermata.Il test è pronto molto prima della funzionalità.Il giorno in cui la funzionalità arriva in staging, la pipeline percorre con i suoi clic l'app reale e segnala, elemento per elemento, se corrisponde al design.
Quando il design cambia: Sincronizza da Figma
I design cambiano, e un test scritto da un design deve cambiare con loro.Quando il design cambia, esportatelo di nuovo da Figma, poi scegliete File, Sincronizza da Figma... in GUI Test Studio.
| Cosa è cambiato nel design | Cosa fa una sincronizzazione |
|---|---|
| Un testo dice qualcosa di diverso | Il controllo si aspetta le nuove parole. |
| Un elemento appare diverso | Il controllo prende la nuova immagine. |
| Un elemento si è spostato o ha cambiato dimensione | Il controllo lo segue, e lo segue anche un clic diretto su di esso. |
| Un elemento non c'è più | Il suo controllo viene rimosso. |
| Un elemento è nuovo | Non selezionato: nulla di nuovo viene controllato se non lo chiedete voi. |
Nemmeno un controllo che avete modificato voi stessi è selezionato, così una sincronizzazione non sovrascrive mai il vostro lavoro senza chiedere.Nulla viene verificato in background: il test cambia solo quando sincronizzate.
È questo che mantiene visibile la deriva del design.Quando il design cambia e la build non lo segue, il test sincronizzato fallisce e dice quale elemento differisce.
Da un design Figma a un test con un assistente IA
Potete anche affidare il design a un assistente IA.Claude, ChatGPT o un modello di IA locale sul vostro computer, uno nostro o uno vostro, collegato a GUI Test Studio, crea il test dal pacchetto di design con la stessa importazione.Vedete Creare un test da un prompt.
Create a test from C:\Designs\Login.gtsdesign, following its prototype flow.Il test viene salvato, e GUI Test Studio si apre su di esso, pronto per la vostra revisione.Si abbina bene a un agente di programmazione basato su IA: l'agente realizza la funzionalità, e il test creato dal design vi dice se ha realizzato ciò che era stato progettato.Vedete Sviluppo con agenti IA.
Buone pratiche
Do
- Esportate il flusso del prototipo, così il test percorre con i suoi clic le schermate in ordine.
- Date nomi chiari alle schermate e alle sezioni, come Login e Header: i controlli di ogni sezione viaggiano come un'unica asserzione di gruppo che porta il loro nome.
- Eseguite il test a ogni build fin dal primo giorno, rosso compreso.
- Accettate una volta l'aspetto reale, dopo la prima esecuzione della funzionalità realizzata.
Avoid
- Controllare contenuti di esempio, come paragrafi segnaposto e foto di repertorio.
- Trattare la prima esecuzione rossa come un test rotto: è l'elenco del lavoro da fare.
- Selezionare ogni nuovo elemento in una sincronizzazione senza guardarlo.
- Scrivere selettori per una schermata che non esiste ancora.
Nessun file Figma?Funzionano anche le immagini di qualsiasi strumento di design, come Sketch o Adobe XD: vedete Testare una funzionalità prima che esista.
Domande
Si possono generare test dai design Figma?
Sì.Il plugin Figma di GUI Test Studio salva le vostre schermate in un unico file di design, e Importa da Figma lo trasforma in un test end-to-end: un'immagine di riferimento per schermata, un controllo per elemento e, per un flusso del prototipo, i clic tra le schermate.Il test viene eseguito sull'app reale una volta realizzata la funzionalità.
Come si fa lo sviluppo guidato dai test per un'interfaccia utente?
Scrivete il test a partire dal design invece che dal codice.Un test che trova ogni elemento da come appare e da ciò che dice può esistere prima della funzionalità.Fallisce finché la funzionalità manca e viene superato quando la build corrisponde al design.
Che cos'è la deriva del design?
La deriva del design è lo scarto che cresce tra un design e il prodotto realizzato a partire da esso: parole cambiate, icone mancanti, caratteri e spaziature che non corrispondono più.Passa inosservata quando nessuno confronta la build con il design.
Qual è la differenza tra la QA del design e il test di regressione visiva?
La QA del design confronta la build con il design.Il test di regressione visiva confronta la build con una build precedente, quindi viene superato anche quando la prima build non ha mai corrisposto al design.
Cosa succede al test quando il design Figma cambia?
Esportate di nuovo il design e scegliete Sincronizza da Figma in GUI Test Studio.Elenca ogni modifica con un segno di spunta, aggiorna solo ciò che lasciate selezionato, e non sovrascrive mai un controllo che avete modificato voi stessi.
GUI Test Studio ha bisogno di accedere al mio account Figma?
No.Il plugin salva un file di design sul vostro computer, e GUI Test Studio legge quel file.Non c'è alcun account da collegare, nessun token da creare, e nulla viene inviato da nessuna parte.
Figma, Selenium, Playwright, Cypress, Storybook, Chromatic, Cucumber, Testsigma, BrowserStack e Applitools sono marchi dei rispettivi proprietari.
Pronti a registrare il vostro primo test?
Tutte le funzionalità, per 15 giorni.
Preferite vederlo sul tipo di app che testate?Prenotate una chiamata gratuita di 30 minuti con il nostro team.