Playwright e MCP: como um agente de IA verifica a interface e o banco de dados sem asserções SQL manuais

Um único aviso verde depois de clicar em "Finalizar pedido" não significa que o pedido foi realmente criado. Se a transação sofreu rollback, uma fila perdeu a mensagem e a interface mostrou "sucesso" mesmo assim, o teste end-to-end passa uma falsa sensação de confiabilidade. Por isso, cada vez mais equipes olham para a verificação full-stack, que checa não só a interface, mas também o estado real dos dados no banco.

Na abordagem clássica, a infraestrutura de testes precisa de acesso direto ao banco via ORM ou driver de baixo nível. Daí começam os custos extras: credenciais separadas, configuração de conexões, asserções SQL manuais e manutenção das consultas a cada mudança de esquema. Formalmente, isso resolve o problema, mas o custo cresce junto com o número de cenários. Cada novo teste end-to-end deixa de ser apenas uma checagem do comportamento do usuário e vira um miniprojeto de manutenção de código de teste.

O artigo analisa um padrão mais leve: um único agente de IA trabalha em sequência com dois servidores MCP. Primeiro, ele executa o cenário no navegador via Playwright como um usuário comum: preenche o carrinho, passa pelo checkout, clica no botão de confirmação e registra os principais sinais do resultado. Depois, o mesmo agente passa para um servidor capaz de ler a estrutura do banco e responder a consultas de verificação sem que o testador escreva SQL à mão.

Na prática, basta o agente formular o que precisa ser confirmado: se existe o registro do pedido, se os itens batem, se o estoque do produto foi baixado, se o status do pagamento mudou. Essa abordagem fecha a principal lacuna entre "a interface mostrou sucesso" e "a operação de negócio realmente foi concluída". O agente pode comparar os dados da interface com os registros das tabelas, verificar efeitos colaterais e até levar em conta a assincronia, caso o sistema não grave no banco de forma instantânea.

Para times de produto, isso é especialmente importante em cenários nos quais um único botão do usuário dispara uma cadeia de ações: criar o pedido, reservar estoque, registrar no sistema de logística, atualizar o status do cliente. É nesses pontos que mais surgem os bugs caros, que um teste de interface comum não pega.

O valor prático do padrão está em reduzir a barreira para testes full-stack. A equipe não precisa levar um ORM para os testes só por causa de algumas verificações, nem duplicar o conhecimento do esquema do banco no código das asserções. Em vez disso, surge uma camada única de verificação baseada em intenções: "após finalizar o pedido, deve aparecer um registro", "a quantidade de itens deve bater", "o estoque do armazém deve diminuir em uma unidade".

Se o esquema muda, a manutenção fica mais perto do servidor MCP ou da descrição de acesso aos dados, em vez de se espalhar por dezenas de testes. Com isso, os testes ficam mais curtos, mais claros e mais próximos da linguagem do negócio.

Ainda assim, esse cenário não dispensa a disciplina básica de engenharia. Não dá para confiar só no agente de IA: testes unitários e de integração continuam necessários para localizar rapidamente erros em funções, serviços e contratos. O acesso do agente ao banco deve ser restrito, de preferência somente leitura e apenas no ambiente de testes. Também são necessárias medidas de previsibilidade: dados de teste estáveis, regras de seleção claras e proteção para que o agente não verifique por engano o pedido errado em um banco compartilhado. Caso contrário, uma ferramenta conveniente vira rapidamente fonte de falhas ruidosas e difíceis de reproduzir.

A principal conclusão é simples: o próximo passo dos testes end-to-end é sair da checagem de telas e passar à checagem das consequências reais da ação do usuário. A combinação de Playwright e MCP torna essa transição bem mais barata, porque tira o SQL manual do dia a dia do testador e permite que uma única automação percorra o caminho do clique no botão até o fato de o registro existir no banco. Para equipes que testam pagamentos, pedidos, reservas e outras transações críticas, isso não é só uma técnica prática, mas um jeito de reduzir testes falso-positivos e pegar mais cedo bugs que antes escapavam para a produção.