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

A parte difícil de um projeto que mexe com infraestrutura real não é escrever a feature — é confiar que uma mudança grande não quebrou nada. Provisionamento, SSH e instalação de serviço testados apenas com mocks dão uma falsa sensação de segurança: validam a forma, não o comportamento. O DevStation seguiu outro caminho — testes via MCP, executados contra um node Proxmox real em homelab.

MCP como superfície de teste

O Model Context Protocol é um padrão aberto para conectar agentes a ferramentas e dados. O engine do DevStation expõe um servidor MCP, e a suíte e2e exercita exatamente a mesma fronteira que um agente usaria: 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 — não conhece 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 não simula o Proxmox; ela conversa com a máquina. Provisiona um node de verdade via OpenTofu, sobe a VM, conecta por SSH, instala, desinstala e destrói. É mais lento que um teste de unidade — e essa é a troca aceita conscientemente: o que ele devolve é comportamento real, não uma aproximação.

Confiança em refatorações grandes

O ganho aparece nos refactors. Ao renomear deploy → install e destroy → uninstall no stack inteiro, o e2e contra o node real apontou em segundos uma regressão que nenhum mock pegaria: a leitura do estado anterior havia quebrado um endpoint. Encontrar isso na hora, e não em produção, é o que torna mudanças amplas viáveis. E como é o agente quem opera a suíte, o ciclo “provisiona → instala → desinstala → destrói” roda em loop, sem supervisão constante. O custo de verificar uma mudança grande caiu para perto de zero.

A jornada cross-OS no Windows

A validação no Windows ilustra bem o método. Duas máquinas — uma Linux, 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; 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 — e os testes via MCP eram executados pelos dois lados sempre que necessário. A fronteira de sistema operacional deixou de ser um evento manual e virou parte do loop.

Disciplina de teste e o papel do harness

Há um trade-off a reconhecer. Existem evidências de que os ganhos de IA diminuem em projetos maduros que o time já domina e de que modelos perdem eficácia em bases muito grandes. O que mudou o resultado foi o harness exigir a disciplina: cada feature nasce com seu teste, cada correção com sua regressão, e o agente executa a suíte real porque a regra manda. A IA não dissolveu a complexidade sozinha; um conjunto de práticas somado a um harness que cobra essas práticas tornou a complexidade administrável. Testar contra o real, em loop, mudou o que é seguro tentar.

Referências

• Model Context Protocol — Anthropic
• Produtividade de desenvolvedores experientes com IA em projetos maduros — METR (2025)
• Dificuldade de LLMs em bases de código grandes — arXiv