Novidades no API Tester: gRPC, Socket.IO, MQTT e scripts de teste de verdade

Em julho apresentamos o API Tester como um cliente completo de REST, WebSocket, GraphQL e SSE integrado à IDE. Desde então ele ganhou uma ficha completa na documentação — e, mais importante, três protocolos totalmente novos, um motor de scripts de verdade e uma forma de manter suas coleções de API completamente fora da nuvem.

Aqui está tudo o que há de novo.

gRPC, por reflexão do servidor

O API Tester agora fala gRPC sem pedir um único arquivo .proto. Aponte para host:porta, toque em Discover services, e ele percorre a API de reflexão do servidor para listar o que pode ser chamado — o mesmo mecanismo usado pelo grpcurl e pelo cliente gRPC do Postman, então funciona contra qualquer servidor que exponha reflexão.

As chamadas são apenas unary: métodos de streaming aparecem na lista, corretamente rotulados e desabilitados, em vez de ficarem ocultos ou fingirem que funcionam. E a interface nunca pede para você preencher um formulário gerado campo a campo — você escreve a requisição em JSON puro, o PocketCode a constrói como um DynamicMessage por baixo dos panos, e você recebe JSON de volta.

Socket.IO, evento por evento

No Socket.IO não existe um catálogo fixo de eventos como no MQTT, então o painel também não finge ter um. Conecte a um namespace, ative a reconexão automática se quiser, e então:

• Adicione um listener para qualquer nome de evento que você espera.
• Emita um evento seu com um payload JSON.

Cada mensagem no log estilo chat é marcada com o evento ao qual pertence, então uma conexão que lida com eventos message, typing e presence continua legível. Por baixo é o cliente oficial socket.io-client-java, então o comportamento é igual ao que você teria com um cliente Node.

MQTT, topic por topic

Construído sobre o cliente da HiveMQ (ele fala MQTT 5, embora o painel atualmente exponha recursos de nível 3.1.1 — ainda sem propriedades do MQTT 5, o que está documentado em vez de simplesmente omitido). Conecte com ou sem TLS, com ou sem usuário e senha, e então:

• Assine um topic com QoS 0, 1 ou 2.
• Publique em um topic com QoS e uma flag opcional de retain.

As mensagens recebidas são agrupadas por topic, então um dispositivo publicando em sensors/+/temp não vira um único fluxo ilegível.

Scripts de teste que realmente rodam

Esse é o que mais nos orgulha, porque substitui algo que na verdade não funcionava. O antigo executor de testes procurava chamadas pm.test('...') por expressão regular e adivinhava o resultado a partir das palavras do nome do teste — um teste chamado "usuário tem papel de administrador" sempre passava, não importa o que a resposta realmente contivesse.

Isso acabou. Duas coisas o substituem:

1. Asserções sem código — escolha um campo (status code, tempo de resposta, um header, um JSONPath dentro do body, tamanho do body), um operador (igual, contém, maior/menor que, existe) e um valor. Sem script, sempre avaliado, e rápido de montar no teclado do celular.
2. Scripts de teste em JavaScript de verdade, rodando em um processo sandbox isolado (androidx.javascriptengine — zero bytes adicionados ao APK, já que se apoia no motor WebView do próprio dispositivo). Um script que lança uma exceção não consegue derrubar o app junto com ele. No raro aparelho sem um WebView moderno, ele cai para um simples aviso no console em vez de fingir silenciosamente que seus testes passaram.

Ambos escrevem seus resultados na mesma aba Tests, e tudo o que um script registra aparece em uma aba Console dedicada — níveis LOG / INFO / WARN / ERROR incluídos.

Coleções que vivem no seu repositório, não na nuvem de outra pessoa

Esta é a funcionalidade que achamos que nenhum outro cliente de API para celular tem: Salvar no projeto espelha uma coleção como um arquivo JSON legível por requisição, em .pocketcode/api/<coleção>/, dentro do mesmo projeto que o seu editor de código já tem aberto.

O Room — o banco de dados local do PocketCode — continua sendo a fonte da verdade no dia a dia. Exportar regenera o diretório inteiro a partir do Room, então é sempre um retrato limpo. Importar mostra uma prévia antes — uma coleção totalmente nova, ou exatamente quantas requisições seriam substituídas — e nada toca o banco de dados até você confirmar. Confirme os arquivos com o gerenciador de Git do próprio app e a revisão da sua coleção de API funciona como qualquer outro pull request, porque é um.

Algumas coisas menores que fazem diferença

• O Histórico ganhou "Comparar com…", um diff de verdade entre duas respostas — linha a linha no body, mais um diff de headers separado — e "Usar como mock", que transforma qualquer resposta passada em uma rota mock com um toque.
• O Executor agora pode iterar sobre um arquivo de dados CSV ou JSON, uma linha por iteração, com cada linha disponível na resolução de variáveis acima do escopo Collection.
• Chegaram as variáveis dinâmicas: {{$guid}}, {{$timestamp}}, {{$isoTimestamp}}, {{$randomInt}}, {{$randomEmail}}, {{$randomFirstName}}, {{$randomLastName}} — o mesmo atalho que você esperaria do Postman, resolvido de novo a cada uso.
• O Mock Server agora pode gerar rotas diretamente de um documento OpenAPI importado, e gravar qualquer resposta do Histórico como fixture de mock.

---

Sete protocolos, scripts de verdade em vez de um palpite, e coleções de API que se versionam como o resto do seu código — tudo ainda rodando totalmente no seu celular, sem nada exigido na nuvem. Se você ainda não viu o resto do módulo, o detalhamento completo está na documentação.

O PocketCode está a caminho da Google Play. Participe da pré-inscrição para estar entre os primeiros a experimentá-lo no seu próprio dispositivo.