Novedades en API Tester: Socket.IO, MQTT y scripts de test reales

En julio presentamos el API Tester como un cliente de REST, WebSocket, GraphQL y SSE integrado en el IDE. Desde entonces ganó una ficha completa en la documentación — y, más importante, dos protocolos nuevos, un motor de scripts real y una forma de mantener tus colecciones de API completamente fuera de la nube.

Esto es todo lo nuevo.

Socket.IO, evento a evento

En Socket.IO no hay un catálogo fijo de eventos como en MQTT, así que el panel no intenta fingir uno. Conecta a un namespace, activa auto-reconexión si quieres, y luego:

• Añade un listener para cualquier nombre de evento que esperes.
• Emite un evento propio con un payload JSON.

Cada mensaje del registro tipo chat va etiquetado con el evento al que pertenece, así que una conexión que maneja eventos message, typing y presence se mantiene legible. Por debajo es la biblioteca oficial socket.io-client-java. No hay cabeceras, auth ni query personalizadas, y los listeners no se pueden quitar una vez añadidos.

MQTT, topic a topic

Construido sobre el cliente de HiveMQ, y habla solo MQTT 5: un broker que solo hable 3.1.1 puede rechazar la conexión, y el panel todavía no tiene propiedades de MQTT 5. Conecta con o sin TLS, con o sin usuario y contraseña, y luego:

• Suscríbete a un topic con QoS 0, 1 o 2.
• Publica en un topic con un QoS (no hay opción de retain).

Los mensajes entrantes se agrupan por topic, así que un dispositivo que publica en sensors/+/temp no se convierte en un único stream ilegible. Aún no hay cancelar suscripción, last will ni certificado TLS propio.

¿Y gRPC?

Cuando se publicó este artículo, también anunciaba un panel gRPC experimental. Ese panel sigue en el código, pero la versión actual de PocketCode lo oculta: gRPC necesita una biblioteca que la app tiene que dejar fuera, así que el panel todavía no puede funcionar en Android. Seguirá oculto hasta que funcione. Hoy el menú de protocolo tiene los seis que sí funcionan: REST, WebSocket, GraphQL, SSE, Socket.IO y MQTT.

Scripts de test que de verdad se ejecutan

Este es del que más orgullosos estamos, porque sustituye algo que en realidad no funcionaba. El antiguo motor de tests buscaba llamadas pm.test('...') por expresión regular y adivinaba el resultado a partir de las palabras del nombre del test — un test llamado "el usuario tiene rol de administrador" pasaba siempre, sin importar lo que la respuesta contuviera de verdad.

Eso desapareció. Dos cosas lo sustituyen:

1. Aserciones sin código — elige un campo (status code, tiempo de respuesta, una cabecera, un JSONPath dentro del body, tamaño del body), un operador (igual, contiene, mayor/menor que, existe) y un valor. Sin script, siempre se evalúa, y rápido de construir con el teclado de un móvil.
2. Scripts de test en JavaScript real, ejecutados en un proceso sandbox aislado (androidx.javascriptengine, que se apoya en el motor WebView del propio dispositivo). Un script que lanza una excepción no puede tumbar la app con él. En el raro dispositivo sin un WebView moderno, cae a un simple aviso en consola en vez de fingir en silencio que tus tests pasaron. Los scripts disponen de un pequeño subconjunto de pm.* (pm.test, pm.expect, pm.environment, pm.response y alguno más), no de toda la API de Postman.

Ambos escriben sus resultados en la misma pestaña Tests, y todo lo que un script registra aparece en una pestaña Console dedicada — niveles LOG / INFO / WARN / ERROR incluidos.

Colecciones que viven en tu repositorio, no en la nube de otro

Guardar en el proyecto espeja una colección como un fichero JSON legible por petición, bajo .pocketcode/api/<colección>/, dentro del mismo proyecto que ya tiene abierto tu editor de código. Lo pulsas tú; nada se espeja de forma automática.

Room — la base de datos local de PocketCode — sigue siendo la fuente de verdad del día a día. Exportar regenera el directorio entero desde Room, así que siempre es una instantánea limpia. Importar te muestra antes una vista previa — una colección completamente nueva, o exactamente cuántas peticiones se reemplazarían — y nada toca la base de datos hasta que confirmas. Confirma los ficheros con el gestor de Git de la propia app y tu colección de API se revisa como cualquier otro pull request, porque lo es. Una cosa a vigilar: los ficheros llevan los valores de auth tal como están guardados en la petición, así que mantén los tokens fuera de lo que subas.

Algunas cosas más pequeñas que suman

• El historial ganó "Comparar con...", un diff real entre dos respuestas — línea a línea en el body, más un diff de cabeceras aparte — y "Usar como mock", que convierte una respuesta pasada en una ruta mock desde un menú.
• El Ejecutor (Pro) ahora puede iterar sobre un fichero de datos CSV o JSON, una fila por iteración, con cada fila disponible en la resolución de variables por encima del scope Collection.
• Llegaron las variables dinámicas: {{$guid}}, {{$timestamp}}, {{$isoTimestamp}}, {{$randomInt}}, {{$randomEmail}}, {{$randomFirstName}}, {{$randomLastName}}, resueltas de nuevo en cada uso.
• El Mock Server (Pro) ahora puede generar rutas directamente desde un documento OpenAPI importado, y una respuesta del historial puede convertirse en ruta mock.

---

Seis protocolos, scripts reales en vez de una suposición, y colecciones de API que se versionan como el resto de tu código — todo guardado en tu teléfono, sin nada requerido en la nube. Si no has visto el resto del módulo, el desglose completo está en la documentación.

PocketCode está disponible en Google Play. Consigue PocketCode