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

Em julho apresentamos o API Tester como um cliente de REST, WebSocket, GraphQL e SSE integrado à IDE. Desde então ele ganhou uma ficha completa na documentação — e, mais importante, dois protocolos 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.

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 é a biblioteca oficial socket.io-client-java. Não há headers, auth nem query personalizados, e os listeners não podem ser removidos depois de adicionados.

MQTT, topic por topic

Construído sobre o cliente da HiveMQ, e fala só MQTT 5: um broker que fale apenas 3.1.1 pode recusar a conexão, e o painel ainda não tem propriedades do MQTT 5. 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 um QoS (não há opção 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. Ainda não há cancelar assinatura, last will nem certificado TLS próprio.

E o gRPC?

Quando este post saiu, ele também anunciava um painel gRPC experimental. Esse painel continua no código, mas a versão atual do PocketCode o oculta: o gRPC precisa de uma biblioteca que o app tem de deixar de fora, então o painel ainda não pode funcionar no Android. Ele fica oculto até que funcione. Hoje o menu de protocolo tem os seis protocolos que funcionam: REST, WebSocket, GraphQL, SSE, Socket.IO e MQTT.

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, 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. Os scripts têm um pequeno subconjunto de pm.* (pm.test, pm.expect, pm.environment, pm.response e mais alguns), não toda a API do Postman.

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

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. Você toca nele; nada é espelhado automaticamente.

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. Um ponto de atenção: os arquivos levam os valores de auth exatamente como estão salvos na requisição, então mantenha tokens fora do que você faz commit.

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 uma resposta passada em uma rota mock a partir de um menu.
• O Executor (Pro) 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}}, resolvidas de novo a cada uso.
• O Mock Server (Pro) agora pode gerar rotas diretamente de um documento OpenAPI importado, e uma resposta do Histórico pode virar uma rota mock.

---

Seis 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 guardado 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á disponível no Google Play. Baixe o PocketCode