Playwright e MCP: como um agente de IA testa UI e banco de dados sem assertions SQL manuais

Um toast verde após clicar no botão "Finalizar compra" não significa que o pedido foi realmente criado. Se a transação foi revertida, a fila perdeu uma mensagem e a UI ainda mostrou "sucesso", o teste end-to-end dá uma falsa sensação de confiabilidade. É por isso que cada vez mais times estão olhando para verificação full-stack, onde não apenas a interface é verificada, mas também o estado real dos dados no banco de dados.

Na abordagem clássica, essa verificação requer que a infraestrutura de testes tenha acesso direto ao BD através de um ORM ou driver de baixo nível. Então começam as despesas gerais: credenciais separadas, configuração de conexão, asserções SQL manuais, manutenção de consultas a cada mudança de esquema. Formalmente isto resolve o problema, mas o custo cresce com o número de cenários.

Cada novo teste end-to-end se torna não apenas uma verificação do comportamento do usuário, mas um mini-projeto de manutenção de código de teste. O artigo aborda um padrão mais leve: um agente AI trabalha sequencialmente com dois servidores MCP de uma vez. Primeiro, através do Playwright ele executa um cenário no navegador como um usuário regular—preenche o carrinho, passa pelo checkout, clica no botão de confirmação e captura indicadores-chave do resultado.

Então o mesmo agente muda para um servidor que pode ler a estrutura do banco de dados e responder consultas de verificação sem o testador escrever SQL manualmente. Essencialmente, o agente só precisa formular exatamente o que precisa ser confirmado: o registro do pedido existe, os itens correspondem, o saldo do produto foi deduzido, o status do pagamento mudou. Essa abordagem fecha a lacuna principal entre "UI mostrou sucesso" e "a operação comercial realmente foi concluída."

O agente pode combinar dados da interface com registros em tabelas, verificar efeitos colaterais e até levar em conta a assincronia se o sistema não escrever no BD instantaneamente. Para times de produto isso é especialmente importante em cenários onde um botão do usuário dispara uma cadeia de ações: criação de pedido, reserva de inventário, escrita no sistema logístico, atualização de status do cliente. É nesses lugares que bugs caros surgem com mais frequência, aqueles que testes normais de UI não pegam.

O valor prático desse padrão é que reduz a barreira para testes full-stack. Times não precisam arrastar um ORM para testes apenas para algumas verificações e duplicar conhecimento do esquema do banco no código de asserção. Em vez disso, há uma única camada de verificação no nível de intenção: "após checkout um registro de pedido deve aparecer," "o número de itens deve corresponder," "o saldo do armazém deve diminuir em uma unidade."

Se o esquema mudar, a manutenção se move mais perto do servidor MCP ou da descrição de acesso aos dados, em vez de se espalhar por dezenas de testes. Como resultado, testes ficam mais curtos, mais compreensíveis e mais próximos da linguagem comercial. Ao mesmo tempo, esse cenário não substitui a disciplina básica de engenharia.

Você não pode confiar apenas no agente AI: testes unitários e de integração ainda são necessários para localizar rapidamente erros no nível de função, serviço e contrato. O acesso ao banco para o agente deve ser restrito, de preferência somente leitura e apenas em ambiente de teste. Medidas de previsibilidade também são necessárias: dados de teste estáveis, regras de seleção claras, proteção contra o agente verificar acidentalmente o pedido errado em um banco compartilhado.

Caso contrário, uma ferramenta conveniente rapidamente se torna uma fonte de falhas ruidosas e difíceis de reproduzir. A principal conclusão aqui é simples: o próximo passo na evolução do teste end-to-end é a transição de verificar telas para verificar as consequências reais da ação do usuário. A combinação Playwright e MCP torna essa transição significativamente mais barata porque remove SQL manual do trabalho diário do testador e permite que uma automação percorra o caminho do clique do botão ao fato do registro do banco de dados.

Para times testando pagamentos, pedidos, reservas e outras transações críticas, isto não é apenas uma técnica conveniente mas uma forma de reduzir o número de testes falsos positivos e pegar bugs mais cedo que antes vazavam para a produção.