O teste é uma parte crítica do fluxo de trabalho de qualquer desenvolvedor. Isso nos ajuda a garantir que nosso projeto manterá um alto nível de qualidade, bem como evitar que quaisquer bugs incômodos se espalhem.
Mas, muitas vezes, os testes automatizados podem ser difíceis de gerenciar. Entre uma quantidade infinita de código para garantir que você está fornecendo cobertura total e lidando com a natureza frágil dos testes de front-end-onde uma simples mudança de seletor pode quebrar completamente um fluxo de trabalho de ponta a ponta-às vezes pode parecer uma difícil batalha.
Ao adicionar testes visuais automatizados , podemos eliminar aqueles testes instáveis , nivelando nossos pipelines de teste, fornecendo essa cobertura (e mais), aproveitando as comparações de imagens inteligentes usando capturas de tela de nosso site ou aplicativo.
Antes de mergulharmos no assunto teste visual, vamos tirar um minuto para nos atualizar sobre os diferentes tipos de testes automatizados e como eles se encaixam. Em seguida, falaremos sobre o que é exatamente o teste visual e como ele pode fornecer outro nível de cobertura de teste para o seu projeto.
Uma rápida olhada em alguns dos tipos de teste automatizado
O teste automatizado é uma parte interessante do ciclo de desenvolvimento. Alguns clientes ou partes interessadas são capazes de ver claramente o valor que eles fornecem, mas outros preferem que qualquer tempo de desenvolvimento seja gasto no desenvolvimento de recursos puros.
Isso às vezes pode ser contra-intuitivo, em que o objetivo do teste automatizado é proteger o negócios ou evitar que a equipe tenha que gastar tempo corrigindo bugs em primeiro lugar. Escrever testes automatizados sólidos pode evitar grandes perdas financeiras! Em última análise, é um risco que alguns estão mais dispostos a correr do que outros.
Felizmente, esse valor nem sempre é difícil de vender, e quando temos tempo para nos concentrar em testes automatizados de qualidade, temos um variedade de opções para lidar com esses testes, como teste de unidade, teste de integração, teste de ponta a ponta e teste visual (que também pode fornecer cobertura estendida para os três primeiros).
Quando aplicado com o pontos fortes de cada tipo de teste, podemos gastar mais tempo escrevendo testes que podem realmente ajudar a proteger nosso trabalho e evitar a frustração de nossos clientes.
Vamos dar uma olhada em como algumas dessas estratégias de teste parecem como na prática.
Teste de unidade
O teste de unidade se concentra em testar áreas menores e focadas de um aplicativo . Quer testar se uma função que calcula o total do pedido após as promoções está funcionando corretamente? Você gostaria de escrever um teste de unidade.
function myBusinessLogic (pricePerItem, quantidade, desconto) {const subtotal=pricePerItem * quantidade; retorno subtotal-(desconto * subtotal); } expect (myBusinessLogic (2, 4,.1)). toEqual (7.2);
A melhor parte dos testes de unidade é que eles são baratos de escrever e não demoram muito para serem executados. É por isso que você costuma ver as empresas gastando muito tempo construindo um pacote de testes de unidade para capturar as partes granulares de um aplicativo.
Mas por causa desse teste focado, o teste de unidade pode não cobrir como essas as peças trabalham juntas, que é onde começamos a nos mover para o teste de integração.
Teste de integração
O objetivo do teste de integração é pegar as partes e componentes menores de um aplicativo e teste como eles funcionam juntos . Um exemplo comum poderia ser como uma parte específica de uma IU responde a interações seguidas por solicitações a um servidor ou banco de dados.
cy.get (‘. Add-to-cart’). Click (); cy.url (). deve (‘conter’,’carrinho’); cy.get (‘. cart li’). contains (‘Meu Item’);
É perfeitamente possível que seu pequeno componente de IU funcione sozinho conforme o esperado. Seus eventos sintéticos podem ser disparados corretamente em uma instância onClick. Esse código que envolve suas solicitações de API pode funcionar perfeitamente com alguns dados simulados. Mas pode haver lacunas entre essas duas partes trabalhando juntas que seus testes de unidade podem não detectar.
Os testes de integração são uma maneira atraente de testar seu aplicativo, mas você pode dar um passo adiante ao tentar testar “Todas as coisas”.
Teste de ponta a ponta
O teste de ponta a ponta captura toda a jornada do usuário de ponta a ponta para um fluxo de trabalho focado. Por exemplo, se estou construindo uma loja de comércio eletrônico, o”caminho feliz”(ou o caminho esperado com a menor resistência) seria encontrar um produto, adicioná-lo a um carrinho e pagar por esses itens. Se estou escrevendo um teste de ponta a ponta, capturaria todo o processo, ou seja, desde encontrar um produto em uma página de lista de produtos até pagar por esse item.
cy.visit (‘/produtos’); cy.get (‘. product a [href=”/product/1234″]’). click () cy.url (). should (‘contain’,’product/1234′);… cy.get (‘. botão de pedido’). click (); cy.url (). deve (‘conter’,’recibo’); cy.get (‘. recibo li’). contains (‘Meu Item’);
A grande parte do teste de ponta a ponta é que ele é essencialmente um grande teste de integração. Você está capturando muitos componentes diferentes do aplicativo, incluindo como a IU funciona, se as APIs estão respondendo corretamente e se essas partes estão funcionando juntas.
O problema é que o teste de ponta a ponta e até mesmo os testes de integração levam mais tempo para serem escritos e também demoram muito mais para serem executados. Então, como podemos aproveitar todas as nossas opções de teste e montar um conjunto de testes que fornecerá uma maneira eficiente de cobrir nosso aplicativo?
Aproveitando os diferentes tipos de teste
Há uma variedade de mentalidades que geralmente descrevem quantos testes de cada tipo você deve gastar tempo escrevendo.
Mike Cohn criou o conceito de”pirâmide de teste”em seu livro Succeeding with Agile.
Ele argumenta que você deve escrever mais testes de unidade, onde são mais baratos de escrever e mais rápidos de executar. Embora seu diagrama original rotule os vários testes de forma um pouco diferente, à medida que você se inclina mais para o teste de integração, eles se tornam mais lentos para executar e mais caros para escrever. Embora esses testes sejam valiosos, você não quer ter tantas integrações ou testes de ponta a ponta quanto faria com os testes de unidade.
Ter esse equilíbrio pode ajudá-lo a se concentrar na captura do ponto crítico partes do aplicativo, como lógica de negócios com testes de unidade e como eles funcionam em conjunto com os testes de integração, mas Kent C. Dodds argumenta que a tecnologia de teste chegou a um ponto em que não há mais grandes compensações de custo para escrever testes de integração, que é onde seu conceito de “troféu de teste” entra.
Em ambientes de desenvolvimento modernos, temos muitas ferramentas incríveis à nossa disposição, como Cypress , Selenium e Playwright , cada um fornecem aos desenvolvedores e engenheiros de controle de qualidade a capacidade de escrever testes que interagem facilmente com navegadores como Chrome e Firefox.
Com o Cypress, escrever um teste que clica em um botão pode parecer tão simples quanto:
cy.get (‘# meu-botão’). click ()
Isso é indiscutivelmente tão simples quanto testar se o botão está funcionando com eventos sintéticos, se não mais simples. A melhor parte é que você está testando como esse botão realmente funciona em um navegador.
Independentemente de qual diagrama você assina, em última análise, o objetivo é pesar as diferentes opções entre custo e velocidade para determinar o ajuste certo para sua aplicação específica. É importante não apenas atingir 100% em seu relatório de cobertura, mas também ter certeza de que a experiência que você está oferecendo aos visitantes está funcionando como deveria.
Mas não importa a combinação de testes que você executa, esses testes programáticos que apenas interagem e testam o DOM (Document Object Model) estão perdendo uma grande peça do quebra-cabeça: como seus visitantes veem visualmente esse aplicativo.
Quais tipos tradicionais de teste não capturam
Conforme você está executando sua unidade, integração e teste de ponta a ponta em seu aplicativo, todos eles têm uma coisa em comum. Eles estão testando o código.
O que quero dizer com isso é que eles não estão testando o que o visitante de seu aplicativo realmente vê.
Se você estiver executando um pacote de testes de integração e como nosso exemplo anterior, testando se alguém pode adicionar um produto a um carrinho e comprá-lo, a cada etapa, você encontra um elemento no DOM por meio do código e confirma que funcionou da mesma maneira.
Isso não testa coisas como se o texto em sua página é legível ou não. Alguém adicionou uma alteração de CSS que acidentalmente flutuou todas as coisas para a esquerda e as inverteu de cabeça para baixo?
Esses tipos de bugs são chamados de”bugs visuais”, onde eles podem passar em todos os seus testes com louvor, mas quando alguém realmente olha para eles, não é bem certo ou pior, completamente inutilizável.
Realisticamente, não podemos esperar fornecer cobertura total de 100% de todos os detalhes de uma interface de usuário com testes tradicionais. Entre a quantidade infinita de estados do aplicativo e o fato de que estamos sempre adicionando novos recursos, ele simplesmente não se dimensiona.
Isso é o que nos leva ao título desta história: Teste visual .
O que é teste visual?
O teste visual captura a saída visível (como uma captura de tela) de um aplicativo e a compara ao mesmo aplicativo em outro ponto no tempo.
Isso geralmente acontece capturando primeiro uma captura de tela de linha de base ou anteriormente capturou a instância do aplicativo com os resultados esperados e comparou cada novo teste com essa linha de base.
Mas conforme seu projeto é desenvolvido, as coisas mudam. Conforme o tempo passa, essa linha de base será atualizada junto com o seu aplicativo, conforme você aprova novas diferenças visuais como alterações aceitas.
Tipos de teste visual
Uma coisa interessante sobre o teste visual está aí são maneiras diferentes de lidar com isso.
Uma abordagem para testar visualmente é usar comparações pixel a pixel nas quais a estrutura de teste sinalizará literalmente qualquer diferença que vir entre duas imagens. Embora essas comparações forneçam um nível de entrada no teste visual, elas tendem a ser instáveis e podem levar a muitos falsos positivos.
Como você pode imaginar, ao trabalhar com a web, as coisas tendem a renderizar sempre-tão ligeiramente diferente entre carregamentos de página e atualizações do navegador. Se o navegador renderizar a página em 1 pixel devido a uma alteração de renderização, seu cursor de texto sendo exibido, ou”apenas porque”, suas implantações podem ser bloqueadas devido a esses testes que falharam.
Seus testes também estão sujeitos a falhas ao lidar com conteúdo dinâmico. Por exemplo, se você executou testes visuais pixel a pixel diários na página inicial deste site, a Smashing Magazine, terá muitos testes reprovados à medida que eles produzem mais e mais conteúdo.
A melhor maneira de lidar com o teste visual é alavancar a tecnologia como IA , onde cada vez que um teste é executado, a estrutura de teste analisa de forma inteligente a captura de tela capturada em comparação com a linha de base.
Isso pode detectar que as duas capturas são diferentes ou até mesmo detectar se é uma mudança de conteúdo em oposição a uma mudança de layout. Ele não sinalizará esse teste como falho se algo não mudou de fato e você pode até adicionar regras para ignorar regiões dinâmicas de um aplicativo que podem mudar devido a esse conteúdo.
Onde o teste visual ajuda
O teste visual prospera ao ser capaz de capturar o estado atual de um aplicativo exatamente como o seu cliente o viu. Isso o torna realmente atraente para qualquer aplicativo que terá pessoas reais interagindo com ele.
À medida que captura esse instantâneo, ele fornece cobertura de muitas partes desse aplicativo, não apenas um único componente granular que você escreveu um teste para. Isso acaba capturando o contexto em torno desse componente, levando a uma cobertura mais ampla.
Essa se torna uma ótima maneira de fornecer ampla cobertura com baixa sobrecarga . De volta à pirâmide de teste ou troféu de teste, podemos fornecer uma cobertura abrangente além de todos os nossos outros testes.
Como funciona o teste visual?
A essência é simples-comparar duas imagens entre si e procurar a diferença-mas é um pouco mais complexo do que isso.
Comparações de imagens
Ao implementar o teste visual, o objetivo será fornecer cobertura para fluxos de trabalho críticos que possam capturar como uma pessoa real está usando o aplicativo. Isso geralmente inclui a primeira tela que alguém pode ver, mas normalmente não é a única tela que eles veem.
Assim como na criação de uma estratégia para executar testes tradicionais, você quer ter certeza de procurar por interações reais que terminam com resultados reais na IU, como adicionar um item a um carrinho de compras ou adicionar um item favorito à sua lista de desejos.
Com isso em mente, você deseja capturar uma imagem de cada etapa do caminho. Por exemplo, se você estava testando uma loja online, pode adicionar etapas para o seguinte:
Lista de produtos carregados em uma página; Página do produto após selecionar um único produto; IU do carrinho na página após adicionar um produto a esse carrinho; Página do carrinho após navegar até o carrinho; Pagamento e remessa UI, uma vez que entra no fluxo de checkout; Página de recibo após a compra bem-sucedida.
Isso irá capturar os resultados de todas as interações à medida que alguém está passando por sua loja online, onde você pode verificar se não só funciona funcionalmente a partir de uma perspectiva de código, mas se a pessoa pode realmente usar seu aplicativo sem bugs visuais interferindo.
Bits técnicos
Conforme você planeja as capturas de tela, precisará de um mecanismo para automatizar essas tarefas. Algo que pode interagir com um navegador baseado em um conjunto de tarefas.
É aqui que as estruturas de automação de navegador populares como Selenium, Cypress e Playwright entram, onde essas estruturas de teste vão vantagem das APIs do navegador para executar seus comandos, encontrando e clicando em coisas como um humano faria, onde você então diria ao framework de teste visual quando capturar o estado da IU visualmente.
No caso do Cypress e Applitools, Cypress iria navegar por cada página, onde o SDK do Applitools extrairia um instantâneo do DOM e enviaria esse instantâneo para a nuvem do Applitools, onde finalmente geraria capturas de tela para comparação.
Nesse ponto, dependendo da plataforma de teste visual, você obterá um conjunto de resultados na forma de diferenças destacadas ou uma bela marca de seleção verde se as coisas parecerem boas.
Integração com estruturas de teste existentes
Como a integração do Cypress e do Applitools acima, a integração normalmente tem baixo atrito. Muitas das plataformas de teste visual disponíveis podem ser integradas diretamente em estruturas de teste existentes, na maioria das vezes depende apenas de quais SDKs eles têm disponíveis.
cy.visit (‘/product/1234′); cy.eyesOpen ({appName:’Loja Online’, testName:’Página do produto’}); cy.eyesCheckWindow (); cy.eyesClose ();
Isso significa que você normalmente não precisa reescrever completamente seu conjunto de testes para fortalecer seus testes e obter cobertura visual; você pode adicionar esses pontos de verificação aos testes que já possui.
Automatizando testes
Felizmente, a automação do desenvolvimento e das tarefas relacionadas ao teste tem amadurecido rapidamente, fornecendo muitas opções excelentes para como podemos automatizar nossos testes.
As soluções tradicionais de CI/CD, como Jenkins ou Travis CI, permitem que você execute seus testes em seus ambientes junto com o restante do pipeline de integração e implantação. Relativamente novas no espaço de automação são ferramentas como GitHub Actions , onde fornecem um mecanismo semelhante aos ambientes tradicionais de CI/CD, mas certo dentro de seu repositório GitHub existente. Isso o torna uma vitória fácil ao tentar executar seus testes e outras tarefas de código automaticamente, onde você não precisa de um sistema totalmente novo, mas em vez disso, usa suas ferramentas existentes.
nome: Node.js CI on: [push, pull_request] jobs: build: runs-on: ubuntu-últimas etapas:-usa: actions/checkout @ v2-usa: actions/setup-node @ v2 com: node-version: 12.x-run: npm ci-run: teste npm
Mas, independentemente do ambiente que você usa, em última análise, você está sujeito aos requisitos da estrutura de teste. Cypress funciona perfeitamente onde quer que você possa instalar o Node.js, o que é bastante comum hoje em dia, contanto que você tenha acesso a um navegador sem interface como Electron ou Chrome. Outros podem exigir um pouco mais de ambiente, mas, nesse ponto, você normalmente pode estruturar esse ambiente como desejar, criando as condições necessárias para executar seus testes.
Quais são os benefícios do teste visual?
O teste visual vai fornecer uma ampla variedade de benefícios como alguns dos que já discutimos, mas realmente ajuda todos os interessados, incluindo executivos, gerentes de produto, desenvolvedores, designers e realmente qualquer outra pessoa da equipe.
Por exemplo, para um CEO ou Gerente de produto, você está ganhando confiança de que sua cobertura de teste está realmente capturando o uso no mundo real . Para a equipe de desenvolvimento, você está ganhando a mesma confiança de que sempre que fizer alterações, receberá feedback imediato, eliminando o fator de medo envolvido ao tentar agir rapidamente. Mas também há muitos benefícios práticos.
Menos código para manter
Ao integrar com uma plataforma de teste visual, a maior parte do seu código girará em torno de duas coisas: interações e capturas de tela.
As interações são essencialmente navegar por um aplicativo, encontrando qual página ou fluxo de usuário você deseja capturar. Independentemente de como você está testando, provavelmente você precisará manter isso de uma forma ou de outra.
As capturas de tela, por outro lado, irão cobrir todas as afirmações que você normalmente escreveria um teste. Ao comparar cada captura de tela com uma linha de base, você automaticamente se certifica de que cada componente do seu projeto está funcionando exatamente como pretendido.
Os testes são menos frágeis
E usando essas capturas de tela como seu mecanismo de asserção, seus testes serão menos instáveis e frágeis.
Se você estiver escrevendo uma asserção contra uma parte específica do DOM, como usar um ID ou um seletor gerado automaticamente, você arriscando uma falha no teste com qualquer alteração nesse componente.
Com um ID, alguém pode simplesmente removê-lo ou alterá-lo acidentalmente. Talvez você tenha pensado que era apenas para fins funcionais e atualizou ao retrabalhar as coisas, o que acabou quebrando o teste (aconteceu comigo!).
Ou se você estiver usando seletores gerais, gerados automaticamente ou não , eles tendem a ser muito específicos, pois você está testando partes muito específicas do aplicativo . Se você acabar aninhando algum HTML ou movendo um pouco as coisas no código, mesmo que não tenha mudado sua aparência visual, isso pode acabar quebrando o teste.
Testando o que as pessoas realmente são Usando
Falando em testar sua aparência visual, ao testar o visual, você está testando o que seus visitantes ou clientes realmente veem.
Usar o HTML semântico adequado não torna seu projeto utilizável. Uma pequena mudança no CSS (como Z-index) pode mudar completamente a usabilidade e a aparência de algo.
Ao capturar uma imagem e comparar o estado real do aplicativo por meio de interações do fluxo de um usuário, você pode ter certeza de que seu aplicativo está funcionando funcionalmente e também de que ele pode ser usado por mais do que apenas robôs de automação.
Leitura recomendada : Gerenciando CSS Z-Index em grandes projetos
Testando coisas que você fez t Think To Test
Você também está obtendo cobertura de diferentes partes de seu aplicativo que você nem pensou em testar.
Considere a lista de testes que você tem em seu suite, esses são os que você pensou em escrever ou escreveu porque você encontrou um bug anteriormente. E quanto ao resto do aplicativo?
Essa captura de tela irá capturar mais detalhes e contexto que seus outros testes podem não ter incluído.
O que o teste visual não cobre?
Mas o teste visual não pretende ser uma solução completa para substituir todo o seu conjunto de testes. Como os outros tipos de teste, ele deve coexistir, preenchendo as lacunas dos outros e, em última análise, fornecendo uma cobertura mais significativa.
Teste de lógica de negócios baseada em dados
Como você’Ao executar testes visuais, você pode ser capaz de capturar alguns aspectos de sua lógica de negócios, como certificar-se de que quando alguém adiciona um item ao carrinho, a matemática verifica, mas sua loja online provavelmente tem uma variedade mais ampla do que apenas isso um produto.
Ainda é importante capturar essa lógica de negócios complexa com testes de unidade, certificando-se de capturar diferentes casos de uso, como vários descontos afetam esse total.
Teste abrangente de API
Ao lidar com APIs, você pode pensar em um teste visual como um teste de integração. Podemos testar que, ao interagir com o navegador, nossa lógica de solicitação está funcionando conforme o esperado. Mas não fornece uma visão abrangente de como essa API está funcionando.
Semelhante à lógica de negócios, sua API ainda deve ser apoiada por um conjunto de testes que garantirá que está trabalhando conforme o esperado, como testes de unidade ou verificações de saúde.
Introdução aos testes visuais
Como outra ferramenta em nosso cinto, os testes visuais podem realmente ajudar a fornecer outro nível de cobertura que nos ajuda a manter um alto nível de qualidade para nossos aplicativos, mas por onde começamos?
Ajustando-se ao ciclo de vida do desenvolvimento
Como o teste visual ajuda a atingir os objetivos de todas as partes interessadas, isso pode realmente se encaixar em qualquer parte do ciclo de vida do desenvolvimento.
Por exemplo, tradicionalmente os testes são usados apenas para validar se o código está funcionando conforme o esperado, mas também podemos usar o teste visual para transferência de design e colaboração UX . Os designers da equipe podem conectar seus mockups como uma linha de base e usá-los facilmente para comparar a experiência real.
Mas de uma perspectiva de código, o teste visual pode prosperar em ambientes automatizados, como a execução de verificações em solicitações pull, em ambientes de teste antes da implantação e certificando-se de que a produção esteja funcionando bem após a implantação.
Você pode até executar seu teste visual em um cron, substituindo seus eventos sintéticos de verificação de integridade, que normalmente são instáveis e nunca realmente informam em que estado seu aplicativo está.
Felizmente, há muitas opções para o serviço que você usa, mas também para os pontos de integração para usar esses serviços.
Soluções disponíveis para testes visuais
A determinação de qual solução seguir em frente depende de escolher a biblioteca ou serviço que você será nós para executar os testes. Como abordamos anteriormente, o maior diferencial será o tipo de teste visual que esses serviços fornecem.
Muitas plataformas estão usando testes visuais pixel a pixel para realizar verificações. Isso inclui ferramentas como Percy e Cromática que irá sinalizar muda entre duas capturas de tela.
Então você tem testes visuais com tecnologia de IA, onde Applitools é realmente o único serviço que está fornecendo atualmente essa capacidade. Em vez de simplesmente verificar as imagens pixel a pixel, o Applitools compara as imagens de maneira inteligente evitando testes instáveis ou falsos positivos , fornecendo detecção de mudança significativa.
Independentemente da solução, você’Em última análise, será necessário integrá-lo ao seu ambiente de desenvolvimento, esteja você começando do zero ou adicionando-o a uma estrutura de teste existente.
Integrando o teste visual
Ao integrar sua plataforma de teste visual de escolha, você tem a opção de começar do zero ou o caminho mais fácil de integração em sua estrutura de teste existente. Ferramentas como Applitools tornam isso fácil, onde a grande variedade de SDKs que são suportados ajuda a facilitar o uso em fluxos de trabalho existentes.
Um bom exemplo disso é se você já estiver configurado e executando o Cypress:
it (‘deve entrar no aplicativo’, ()=> {cy.get (‘# nome de usuário’). type (‘colbyfayock’); cy.get (‘# senha’). type (‘Password1234’); cy.get (‘# log-in’). Click (); cy.get (‘h1’). Contains (‘Dashboard’);});
Se você já estiver realizando testes programáticos, pode simplesmente criar uma camada de teste visual para fornecer outra camada de cobertura.
it (‘deve fazer login no aplicativo’, ()=> {cy.eyesOpen ({ appName:’My App’, testName:’Login’}); cy.get (‘# username’). type (‘colbyfayock’); cy.get (‘# password’). type (‘Password1234’); cy.get (‘# log-in’). click (); cy.eyesCheckWindow (); cy.eyesClose ();});
E alguns SDKs tornam isso ainda mais fácil, onde se você já estiver executando uma biblioteca de Storybook, tudo o que você precisa fazer é instalar o pacote com npm e executar um comando simples, então você terá uma cobertura completa de todos os seus componentes.
npm install @ applitools/eyes-storybook–save-dev npx eyes-storybook
Em última análise, a maior questão é qual framework de teste você deseja usar e se o serviço que deseja usar oferece suporte a esse framework.
Usos criativos de testes visuais
Além de obter outro nível de cobertura de teste para seu aplicativo, há uma variedade de outras maneiras de tirar proveito dos testes visuais.
Monitoramento de tempo de atividade
Regularmente execute um teste visual significativo em vez do monitoramento de tempo de atividade típico com eventos sintéticos frágeis. Design/Colaboração UX
De transferência a questões de usabilidade, use o teste visual para dar a toda a equipe um meio para colaborar. Teste de acessibilidade
Capture os principais problemas que podem limitar a acessibilidade de seu aplicativo. Instantâneos históricos
A execução periódica de um teste visual pode ajudá-lo a capturar instantâneos, fornecendo facilmente uma forma de referenciar um estado mais antigo do projeto. Teste de localização
Com o teste visual baseado em IA capaz de detectar alterações no conteúdo, você tem a capacidade de garantir que tudo está parecendo e funcionando conforme o esperado, independentemente do idioma. Bônus: você pode reduzir a sobrecarga ao tentar comparar diferentes versões de um determinado idioma.
Ao adicionar o elemento visual aos seus testes, você ganha mais opções para adicionar maneiras significativas de manter um alto nível de qualidade para o seu aplicativo.
