O cenário
O Playwright Automation Lab possui testes de API e UI executados em Chromium, Firefox e WebKit. O cenário de Web Tables realiza um CRUD: cria um registro, localiza a linha pelo e-mail, edita o departamento e exclui o registro.
Localmente, o fluxo funcionava. No GitHub Actions, porém, a etapa de edição falhava de forma consistente nos três projetos de browser.
O ponto importante: quando a mesma falha aparece em vários engines no mesmo ambiente, vale investigar primeiro o que esse ambiente tem em comum antes de tratar cada browser como um problema independente.
O erro não estava no locator
O Playwright encontrava o botão de edição. O elemento estava visível, habilitado e estável. Ainda assim, o clique não era concluído porque outro elemento da página interceptava os eventos de ponteiro.
Isso muda completamente o diagnóstico: não era um problema de encontrar o elemento nem simplesmente de “esperar mais”. O teste estava tentando interagir com o alvo correto, mas a geometria da página no CI permitia que uma área lateral do DemoQA ficasse sobre a região da tabela.
Hipóteses precisam ser testadas, não assumidas
Uma hipótese razoável era diferença de viewport. Fixar dimensões explícitas poderia tornar o layout mais próximo do ambiente local. A hipótese foi testada, mas a falha continuou. Isso foi útil: uma tentativa que não resolve o problema também produz informação e reduz o espaço de busca.
O próximo passo foi voltar às evidências da execução — logs, screenshots e trace — em vez de continuar alterando configuração global.
A causa raiz
O problema estava ligado a elementos de publicidade e ao container estrutural lateral do DemoQA. No CI, essa região podia interceptar os eventos destinados aos botões da Web Table.
Como a publicidade não fazia parte do comportamento que o cenário pretendia validar, a solução foi neutralizar especificamente a interferência antes de executar as ações da tabela:
private async disableDemoQaInterference() {
await this.page.addStyleTag({
content: `
#fixedban,
#RightSide_Advertisement,
[id^="Ad.Plus-"],
[id^="google_ads_"],
iframe[title="3rd party ad content"],
iframe[aria-label="Advertisement"] {
pointer-events: none !important;
}
.col-12.mt-4.col-md-3.col-xl-3 {
pointer-events: none !important;
}
`,
});
}Por que não usar force: true?
force: true poderia fazer o clique acontecer, mas reduziria o valor da verificação de actionability do Playwright. Se a aplicação real estivesse cobrindo um botão por erro de layout, forçar a interação poderia transformar um defeito legítimo em teste verde.
Neste laboratório, a interferência vinha de uma área externa ao comportamento testado. Por isso, o tratamento ficou explícito e localizado no Page Object do DemoQA, mantendo os cliques normais no fluxo funcional.
O que esse caso ensina
- “Passa localmente” não prova estabilidade. O CI adiciona outro ambiente de renderização e execução.
- Leia a mensagem de actionability. “Intercepts pointer events” aponta para uma classe de problema diferente de timeout de carregamento.
- Não transforme timeout em solução padrão. Mais tempo não corrige sobreposição de elementos.
- Teste uma hipótese por vez. Viewport foi uma hipótese válida; o fato de não resolver ajudou o diagnóstico.
- Use Trace, logs e screenshots como instrumentos de engenharia. Eles existem para reduzir especulação.
- Diferencie AUT, ambiente e teste. A correção correta depende de saber qual camada está produzindo a falha.
Resultado
Com a interferência externa neutralizada, a suíte voltou a executar de forma consistente no pipeline: seis cenários distribuídos pelos três projetos do Playwright, totalizando 18 execuções.
O aprendizado mais relevante não foi a regra de CSS. Foi o processo: observar a falha, classificar o sintoma, testar hipóteses, usar evidências e aplicar a menor intervenção compatível com a causa encontrada.