Gere testes a partir de designs do Figma antes de o código existir
Gere testes a partir de designs do Figma antes de o código existir: desenvolvimento orientado a testes para a interface, QA de design sem seletores, e asserções que se sincronizam com o design.
10 min de leituraPela equipe do GUI Test Studio
Por que gerar testes a partir de designs do Figma?
Os seus designers já escreveram a especificação mais precisa que a sua equipe tem.Um arquivo do Figma diz o que cada tela deve mostrar: as palavras de cada botão, os ícones, a ordem dos campos, a tela que vem depois de um clique.Mesmo assim, a maioria das equipes escreve os testes de ponta a ponta semanas depois, a partir do aplicativo pronto, e confere o design no olho nesse meio-tempo.
O desenvolvimento orientado a design inverte essa ordem.
- É o desenvolvimento orientado a testes em que o design, e não o código, é a especificação de onde sai o primeiro teste.
- Você gera testes a partir de designs do Figma no dia em que o design é aprovado.
- O teste falha enquanto o recurso não existe.
- Ele passa no dia em que o build corresponde ao design.
- A partir daí, ele mantém o build fiel sempre que o design ou o código mudam.
Este artigo explica o desenvolvimento orientado a testes, por que os testes de ponta a ponta codificados não podem ser escritos primeiro, o que são o design QA e o desvio de design, e como o GUI Test Studio, uma suíte de testes de ponta a ponta para aplicativos de desktop e aplicativos web, transforma um design do Figma em um teste que é executado.
TDD, ATDD e BDD em um minuto
As três são maneiras de escrever o teste primeiro.Elas diferem no que serve de base para o teste e em quem o lê.
| Prática | O teste é escrito a partir de | Quem o lê |
|---|---|---|
| Desenvolvimento orientado a testes (TDD) | Uma pequena parte do comportamento que o código deve ter | Desenvolvedores |
| Desenvolvimento orientado a testes de aceitação (ATDD) | Os critérios de aceitação que a equipe combinou com o negócio | A equipe inteira |
| Desenvolvimento orientado a comportamento (BDD) | Cenários em palavras simples, muitas vezes escritos como Given, When, Then com uma ferramenta como o Cucumber | A equipe inteira |
O ciclo do TDD tem três tempos.
Por que não dá para escrever um teste de ponta a ponta antes do código?
O TDD funciona bem para funções e APIs.Na interface do usuário, ele costuma parar.O motivo é o jeito como os testes de ponta a ponta codificados encontram as coisas na tela.
Um teste do Selenium, do Playwright ou do Cypress encontra cada elemento por um localizador: um id, um seletor CSS, um XPath, um papel e um nome.O Selenium documenta oito estratégias de localização, do id ao XPath.O Cypress recomenda um atributo dedicado, como data-cy, em cada elemento que um teste toca.
cy.visit('/reports');
cy.get('[data-cy=export-pdf]')
.click();Os snapshots visuais codificados também partem do build.O Playwright cria as capturas de tela de referência na primeira execução, então a imagem com que um teste compara é o aplicativo como foi construído, não como foi desenhado.O Storybook com o Chromatic compara cada story de componente com a linha de base aprovada, o que detecta as mudanças entre builds.
Então, na prática, o teste de ponta a ponta é escrito depois do recurso, por alguém olhando o aplicativo pronto.Depois ele verifica que o aplicativo continua fazendo o que faz hoje, seja ou não o que foi desenhado.
Design QA e desvio de design
Definição
O design QA é a conferência de que o build corresponde ao design.
- Na maioria das equipes ele é feito no olho depois do handoff do design: um designer coloca o frame do Figma ao lado do aplicativo de staging e lista o que difere.
Definição
O desvio de design é a distância que cresce entre o design e o produto quando ninguém confere.
- Um rótulo ganha outras palavras no código.
- Um peso de fonte não é o do design system.
- Falta um ícone em uma tela.
Cada mudança é pequena, e juntas elas deixam o produto com cara de inacabado.
Várias ferramentas já vão do Figma a casos de teste.
Testsigma
A IA generativa do Testsigma escreve cenários e casos de teste a partir de frames do Figma, depois que um id de equipe do Figma e um token de acesso são configurados.
BrowserStack Test Companion
O BrowserStack Test Companion lê um link do Figma colado e escreve casos de teste, ou scripts de automação no seu framework.
Applitools Eyes
O Applitools Eyes permite que um teste automatizado use um frame do Figma como linha de base visual.
Os casos de teste escritos ajudam de verdade no planejamento, mas uma pessoa ainda precisa executá-los ou transformá-los em código.Um script gerado, como qualquer teste visual codificado, ainda chega a cada elemento por um localizador que só existe depois que o recurso é construído.Para uma visão mais ampla das ferramentas de ponta a ponta, veja o estudo comparativo.
Como gerar testes de ponta a ponta a partir de um design do Figma?
É assim que o GUI Test Studio verifica uma tela.Uma asserção visual encontra um elemento pela visão e o compara com a imagem que você espera.Uma asserção textual lê as palavras na tela.Um design já contém cada imagem e cada palavra de que essas asserções precisam.
| O que o design do Figma contém | O que o teste recebe |
|---|---|
| Cada tela | Uma imagem de referência da tela |
| As palavras de um rótulo, de um título ou de um botão | Uma asserção textual que aguarda essas palavras |
| Um valor que muda, como uma data ou um valor em dinheiro | Uma asserção textual dinâmica que aguarda um valor do mesmo tipo |
| Um ícone, um logotipo ou uma imagem | Uma asserção visual que busca essa imagem |
| As seções de uma tela, como o cabeçalho ou o formulário | Uma asserção de grupo por seção, que também pode verificar a disposição |
| Os links de um fluxo de protótipo | Os cliques que levam de uma tela à seguinte |
Design
As telas do Figma aprovadas
Vermelho
O teste falha: o recurso ainda não está lá
Build
Um desenvolvedor ou um agente de programação com IA escreve o recurso
Verde
O build corresponde ao design
Desenvolvimento orientado a testes para a interface, etapa por etapa
- 1
Gere o teste a partir do design aprovado
No dia em que o design é aprovado, importe-o.O teste passa a descrever a tela como ela foi desenhada, antes que alguém escreva o recurso.
- 2
Veja-o falhar: essa é a etapa vermelha
Execute-o no aplicativo de hoje.A nova tela não está lá, então as asserções dela falham.O vermelho é o objetivo: o teste é a lista do trabalho que ainda falta.
- 3
Construa até ficar verde
Um desenvolvedor, ou um agente de programação com IA, constrói o recurso.O seu pipeline executa o teste a cada build com o gtr-cli.O Relatório de confiança diz, elemento por elemento, o que já corresponde ao design e o que não corresponde.
- 4
Aceite a aparência real uma vez
Um design e uma tela real raramente correspondem pixel a pixel, porque as fontes são renderizadas de um jeito um pouco diferente.Depois da primeira execução real, aceite a aparência obtida uma vez pelo Relatório de confiança.A partir daí, o teste compara com a coisa real.Veja Quando o aplicativo muda de propósito.
- 5
Refatore com o teste de guarda
Mude o visual do aplicativo, refatore-o, troque o framework dele.O teste não lê o seu código, então continua passando enquanto a tela estiver certa.Ele falha quando um usuário veria uma diferença.
Importar do Figma: o teste antes do recurso
O GUI Test Studio faz tudo isso com Importar do Figma.
- Um pequeno plugin roda dentro do Figma e salva o seu design como um único arquivo, um pacote de design.
- O GUI Test Studio pega esse arquivo.
- Não há conta do Figma para conectar nem token de acesso para criar, e nada é enviado a lugar nenhum.
O plugin do Figma
Salva as telas que você marcar como um único arquivo de design
A sua pasta Downloads
O GUI Test Studio a observa e pega o arquivo
A revisão
Cada elemento, com a asserção que recebe
O teste
Um cenário: imagens, asserções e cliques
O plugin é instalado com o GUI Test Studio.Você o adiciona uma vez no aplicativo de desktop do Figma, em Plugins, Desenvolvimento, Importar plugin do manifesto....
No GUI Test Studio, escolha Arquivo, Importar do Figma...: a janela aguarda o seu design.No Figma, inicie o plugin e marque as telas que você quer, ou escolha um fluxo de protótipo.As telas dele chegam então em ordem, com os cliques que levam de uma à seguinte.Deixe o arquivo exportado na sua pasta Downloads: o GUI Test Studio observa essa pasta e abre o design em um ou dois segundos.
A revisão mostra cada tela com uma caixa em volta de cada elemento, e diz qual asserção cada um recebe.
- Um texto só é verificado como texto quando ele realmente pode ser lido na imagem.
- Palavras pequenas ou claras demais recebem uma asserção visual no lugar, e a lista diz por quê.
- Parágrafos longos e fotos grandes são listados mas não marcados, porque costumam ser conteúdo de exemplo.
Clique em Importar, e tudo chega como um único cenário com o nome do seu design.Cada tela vira uma imagem na faixa Referência visual.As asserções dela vão para a faixa Asserções, agrupadas por seção.Em um fluxo de protótipo, o clique que leva à próxima tela é dirigido ao botão de onde o design faz o link.
O seu designer termina o fluxo “Entrar”: Login, depois Painel, depois Configurações.Você importa o fluxo e recebe três imagens, o clique em Entrar, o clique na engrenagem das configurações e as asserções de cada tela.O teste fica pronto muito antes do recurso.No dia em que o recurso chega ao staging, o pipeline clica pelo aplicativo real e relata, elemento por elemento, se ele corresponde ao design.
Quando o design muda: Sincronizar do Figma
Os designs mudam, e um teste escrito a partir de um design precisa mudar com eles.Quando o design muda, exporte-o de novo do Figma e escolha Arquivo, Sincronizar do Figma... no GUI Test Studio.
| O que mudou no design | O que uma sincronização faz |
|---|---|
| Um texto diz outra coisa | A asserção espera as novas palavras. |
| Um elemento está com outra aparência | A asserção recebe a nova imagem. |
| Um elemento se moveu ou mudou de tamanho | A asserção o acompanha, e um clique dirigido a ele também. |
| Um elemento não está mais lá | A asserção dele é removida. |
| Um elemento é novo | Não marcado: nada novo é verificado a menos que você peça. |
Uma asserção que você mesmo editou também não vem marcada, então uma sincronização nunca substitui o seu trabalho sem perguntar.Nada é conferido em segundo plano: o teste só muda quando você sincroniza.
De um design do Figma a um teste com um assistente de IA
Você também pode entregar o design a um assistente de IA.O Claude, o ChatGPT ou um modelo de IA local no seu próprio computador, um dos nossos ou um seu, conectado ao GUI Test Studio, cria o teste a partir do pacote de design pela mesma importação.Veja Criar um teste a partir de um prompt.
Create a test from C:\Designs\Login.gtsdesign, following its prototype flow.O teste é salvo, e o GUI Test Studio abre nele, pronto para a sua revisão.Ele combina bem com um agente de programação com IA: o agente constrói o recurso, e o teste feito a partir do design diz se ele construiu o que foi desenhado.Veja Desenvolvimento com agentes de IA.
Boas práticas
Do
- Exporte o fluxo do protótipo, para que o teste clique pelas telas em ordem.
- Dê às telas e às seções nomes claros, como Login e Cabeçalho: as asserções de cada seção viajam como uma única asserção de grupo com o nome delas.
- Execute o teste a cada build desde o primeiro dia, vermelho incluído.
- Aceite a aparência real uma vez, depois da primeira execução do recurso construído.
Avoid
- Verificar conteúdo de exemplo, como parágrafos de preenchimento e fotos de banco de imagens.
- Tratar a primeira execução vermelha como um teste quebrado: ela é a lista do trabalho a fazer.
- Marcar todos os elementos novos em uma sincronização sem olhar para eles.
- Escrever seletores para uma tela que ainda não existe.
Não tem um arquivo do Figma?Imagens de qualquer ferramenta de design, como o Sketch ou o Adobe XD, também funcionam: veja Testar um recurso antes que ele exista.
Perguntas
Dá para gerar testes a partir de designs do Figma?
Sim.O plugin do Figma do GUI Test Studio salva as suas telas como um único arquivo de design, e Importar do Figma o transforma em um teste de ponta a ponta: uma imagem de referência por tela, uma asserção por elemento e, para um fluxo de protótipo, os cliques entre as telas.O teste é executado no aplicativo real depois que o recurso é construído.
Como fazer desenvolvimento orientado a testes para uma interface de usuário?
Escreva o teste a partir do design em vez do código.Um teste que encontra cada elemento pela aparência e pelo que ele diz pode existir antes do recurso.Ele falha enquanto o recurso não existe e passa quando o build corresponde ao design.
O que é desvio de design?
O desvio de design é a distância que cresce entre um design e o produto construído a partir dele: palavras alteradas, ícones que faltam, fontes e espaçamentos que não correspondem mais.Ele passa despercebido quando ninguém confere o build com o design.
Qual é a diferença entre design QA e testes de regressão visual?
O design QA confere o build com o design.Os testes de regressão visual conferem o build com um build anterior, então passam mesmo quando o primeiro build nunca correspondeu ao design.
O que acontece com o teste quando o design do Figma muda?
Exporte o design de novo e escolha Sincronizar do Figma no GUI Test Studio.Ele lista cada mudança com uma marca, atualiza só o que você mantiver marcado e nunca substitui uma asserção que você mesmo editou.
O GUI Test Studio precisa de acesso à minha conta do Figma?
Não.O plugin salva um arquivo de design no seu computador, e o GUI Test Studio lê esse arquivo.Não há conta para conectar, nem token para criar, e nada é enviado a lugar nenhum.
Figma, Selenium, Playwright, Cypress, Storybook, Chromatic, Cucumber, Testsigma, BrowserStack e Applitools são marcas registradas de seus respectivos proprietários.
Pronto para gravar o seu primeiro teste?
Todos os recursos, por 15 dias.
Prefere ver no tipo de aplicativo que você testa?Agende uma chamada gratuita de 30 minutos com a nossa equipe.