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

Num projeto que mexe com infraestrutura real, os testes que valem são os que de fato provisionam, instalam e derrubam as coisas. O engine do DevStation expõe um servidor MCP, então a suíte e2e dirige o CLI por ele — a mesma fronteira que um agente, ou qualquer cliente MCP, usaria. São testes de integração comuns; o que o MCP acrescenta é que um agente consegue rodar e explorar o fluxo inteiro sozinho, do jeito que um QA percorreria o CLI na mão.

MCP como superfície de teste

O Model Context Protocol é um padrão aberto para conectar agentes a ferramentas e dados. Na prática, a suíte passa pelas 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 — 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 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, exercita comportamento real de ponta a ponta, 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 práticas. E como é o agente quem dirige a suíte, o ciclo “provisiona → instala → desinstala → destrói” roda em loop sem supervisão constante, então rechecar uma mudança grande continua barato.

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

Nada disso quer dizer que a IA fez a complexidade sumir. O que manteve as coisas honestas 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 real, em loop, foi principalmente o que mudou o quanto parecia seguro tentar. (Há também pesquisa útil sobre onde o ganho da IA diminui — em bases maduras que o time já domina e em bases muito grandes — nos links abaixo.)

Referências

• Model Context Protocol — Anthropic
• Produtividade de desenvolvedores experientes com IA em projetos maduros — METR (2025)
• LongCodeBench: modelos de código em contextos de 1M tokens — arXiv (2025)