Como evito que os testes E2E quebrem a cada mudança na interface?

Testes E2E quebram após uma mudança na interface porque encontram elementos por uma classe, um id, um trecho de texto ou uma posição, e é justamente isso que um redesign altera. O Nexus Studio, da Verdict System LLC, resolve isso em três etapas: propõe um novo locator e pede permissão antes de alterar o teste, marca como AUTO_RECOVER uma execução que um seletor reparado salvou, em vez de contá-la como um pass limpo, e lista os locators frágeis para que você os corrija primeiro.

Pela equipe do Nexus Studio, Verdict System LLC. 7 de outubro de 2026.

Por que testes Playwright e Selenium falham quando a interface muda?

Um locator é o endereço que um teste usa para encontrar um elemento. Quando esse endereço depende de algo que não faz parte do que o elemento faz, como uma classe gerada no build, uma posição na página ou o texto de um rótulo, uma mudança na página torna o endereço inválido e o teste falha nessa linha, mesmo que a aplicação continue funcionando.

O custo não é a falha isolada. É o tempo que a equipe gasta lendo execuções vermelhas, encontrando a linha, buscando um novo locator e editando o arquivo, de novo a cada release.

Qual é o problema do self-healing que corrige testes silenciosamente?

Uma ferramenta que troca um seletor quebrado sem avisar ninguém mantém a suíte verde, mas também esconde a mudança. O teste agora clica em algo que o autor não escolheu, e ninguém revisou. Se a nova correspondência for o elemento errado, o teste pode passar enquanto verifica a coisa errada.

O Nexus Studio foi construído sobre a regra oposta: nada é reparado pelas suas costas.

Como o Nexus Studio repara um seletor quebrado?

• Com o self-healing na configuração padrão, Suggest, quando um teste falha, o Studio abre um navegador em segundo plano, reproduz o teste até a linha que falhou e lê a página. Os candidatos já estão prontos quando você abre a falha. Isso não usa IA, e o teste continua vermelho.
• Na margem (gutter) da linha com falha, a opção Repair line permite regravar apenas aquele passo ou trocar o seletor por um dos candidatos. Os candidatos são ordenados do mais forte para o mais fraco, e o XPath vem por último.
• A alteração chega ao editor sem ser salva. Salvá-la é a sua aprovação.
• Você também pode perguntar à sua IA qual candidato escolher. Ela pode reordenar os candidatos, mas nunca adicionar um, e a versão anterior do arquivo continua na linha do tempo do arquivo.

O que significa quando um teste passa com um seletor reparado?

O veredito é AUTO_RECOVER: a execução passou, mas o self-healing precisou substituir um seletor nesse teste. Ele nunca é reportado como SECURE, a aprovação limpa. O seletor que o autor escreveu está morto, e a próxima mudança na página quebra a suíte de verdade, então a ressalva permanece visível no relatório e em History até que alguém corrija o seletor original.

AUTO_RECOVER é um dos sete veredictos de aprovação, então um job de CI termina com código 0 nele. A ressalva aparece no relatório, não como um build quebrado. A ordem completa das verificações está em How Nexus Studio decides 14 test verdicts.

Como encontrar seletores fracos antes que quebrem?

• Locator health lista os seletores fracos do teste aberto, com a linha de cada um, e os repara pelo mesmo diálogo da Repair line.
• Os Mapas de seletores analisam uma página sem IA, classificam cada seletor como ALTO, MÉDIO ou BAIXO e mantêm o mapa no seu disco.
• O Vet, as sete verificações que todo teste escrito por IA precisa passar, inclui a regra de que o teste não tenha seletores frágeis.

Quais seletores o Recorder escolhe?

O Nexus Recorder escreve o que você clica como código de teste, sem IA no processo. Ele pode usar um atributo de test id: quando você escolhe data-testid para uma gravação em JavaScript, ele lê data-testid e também data-qa. As gravações em Python e Selenium mantêm o único nome de atributo do seu runner. Seletores escritos com esses atributos são classificados como robustos, enquanto um nome de classe gerado pelo build, uma cadeia profunda de CSS e um nome de tag isolado são classificados como frágeis.

O teste continua sendo um arquivo Playwright ou Selenium padrão?

Sim. Todo teste que o Studio escreve ou importa é código de framework que sua equipe já conhece: um arquivo Playwright Test (JavaScript, TypeScript, Python ou C#), ou Selenium (JavaScript, Python, Java ou C#). Um reparo edita uma linha desse arquivo, então não há formato proprietário do qual migrar se você deixar de usar o Studio.

Limites

• O self-healing no modo Suggest não corrige nada sozinho. Uma pessoa ainda aprova cada reparo, então uma grande mudança de interface ainda exige tempo de revisão.
• A leitura automática após uma falha precisa de memória livre na máquina. Quando não há o suficiente, ela não inicia, e você ainda pode pedir os candidatos manualmente.
• O Locator health lê o arquivo linha por linha, então um seletor dividido em várias linhas não é detectado.
• Um seletor fraco que ainda funciona não é uma falha. O Locator health avisa sobre ele, mas nada obriga você a alterá-lo.

Onde posso ver isso funcionando?

O Studio tour mostra a Repair line e o locator health na tela, o guia de veredictos explica o AUTO_RECOVER ao lado dos outros 13 veredictos, e o teste de 30 dias executa o mesmo mecanismo nos seus próprios testes.