Testes via MCP: rodando a suíte contra um homelab real

Durante a renomeação de deploy para install no stack inteiro do DevStation, a suíte e2e, os testes de ponta a ponta que exercitam o sistema inteiro, apontou em segundos uma regressão que nenhum mock teria pegado: a leitura do estado gravado pela versão anterior tinha quebrado um endpoint. O teste rodava contra um node Proxmox de verdade, provisionado e destruído pelo próprio fluxo, e é sobre esse arranjo que este texto trata.

MCP como interface, não como categoria de teste

O engine do DevStation expõe um servidor MCP, e a suíte e2e dirige o CLI por ele. São testes de integração comuns, e o MCP não cria uma categoria nova de teste: ele é a interface pela qual a suíte, e qualquer agente, opera o sistema. O Model Context Protocol é um padrão aberto para conectar agentes a ferramentas e dados, e na prática a suíte executa as mesmas chamadas que um agente faria: listar clusters, provisionar um node, instalar um serviço por SSH, desinstalar, destruir. Por desenho, o MCP é um inbound adapter que traduz as ferramentas em chamadas JSON-RPC já existentes, sem conhecer a estrutura interna dos contextos, com uma allowlist explícita e metadados de risco para as operações destrutivas.

Infraestrutura real no lugar de mocks

A suíte conversa com uma máquina real em vez de uma simulação: provisiona um node via OpenTofu, sobe a VM, conecta por SSH, instala, desinstala e destrói. É mais lento que um teste de unidade, e em troca o que se verifica é o que de fato aconteceu: um comando foi executado, um recurso foi criado, a resposta foi inspecionada, e no fim tudo foi destruído.

O ciclo que ficou repetível

Foi esse arranjo que segurou os refactors grandes. No caso da renomeação, o ciclo rodou completo: a mudança no código, a suíte contra o node real, o endpoint quebrando, a correção da leitura do estado e uma nova execução até passar. Encontrar a regressão na hora, e não em produção, é o que tornou viável mudar nomes que atravessam contrato, domínio e persistência. E como é o agente quem dirige a suíte, repetir o ciclo depois de cada ajuste custa pouco.

A validação no Windows

Duas máquinas, uma Linux e uma Windows, compartilhavam um diretório, com o Claude Code rodando nas duas. O agente no Linux compilava o binário e publicava os artefatos, e o agente no Windows validava, guiado por instruções em arquivos .md. Os dois rodaram por horas, de forma quase autônoma, até o CLI inteiro passar no Windows, com os testes via MCP executados dos dois lados sempre que necessário. A validação no Windows deixou de depender de eu lembrar de repetir uma checklist no fim de cada mudança e passou a entrar no mesmo ciclo, o que é bom, porque eu esqueceria.

Disciplina de teste e o papel do harness

Nada disso quer dizer que a IA fez a complexidade sumir. O que manteve a disciplina foi o harness: cada feature nasce com seu teste, cada correção com sua regressão, e o agente roda a suíte real porque esse é o fluxo. Testar contra o ambiente real, em loop, foi o que mais mudou a noção do que era seguro tentar neste projeto.

Referências

• Model Context Protocol, Anthropic