Header Ads Widget

Ticker

6/recent/ticker-posts

Revisión de la herramienta de prueba de API de Everest

 Echamos un vistazo a Everest, un proyecto de prueba de API de código abierto. 


Las pruebas son una parte fundamental del ciclo de desarrollo de la API. En consecuencia, las herramientas utilizadas para las pruebas son tan esenciales como la prueba en sí. En el ciclo de desarrollo promedio, se pasarán y probarán miles, quizás decenas de miles, de consultas de API para garantizar la integridad de los datos, la claridad de la respuesta y la experiencia del usuario.

Everest es una herramienta que promete proporcionar un entorno excelente para realizar pruebas en una distribución ligera. ¿Está a la altura de su promesa?

¿Qué es el Everest?

Creado por Rohit Awate , Everest es un cliente de prueba de API de código abierto que está diseñado para ser liviano, portátil y personalizable. Originalmente llamado RESTaurant, el cliente está construido en JavaFX e incluye un servidor de sincronización personalizado llamado Summit . En conjunto, la aplicación ofrece una excelente manera de probar API sin la sobrecarga significativa de grandes clientes con funciones de llamada complejas.

Tanto el Everest como el Summit están todavía muy temprano en desarrollo, por lo que gran parte de la promesa de esta solución existe en forma de lista de deseos; en otras palabras, el Everest y Summit todavía tienen mucho camino por recorrer. Everest está planificando la compatibilidad total con ambos estándares OAuth, enfocándose primero en OAuth 2.0 y luego en OAuth 1.0, pero a partir de hoy, tampoco es compatible. Los objetivos a largo plazo de Everest según su documentación son ser el "equivalente de Postman Collection o Insomnia's Workspace", admitiendo una amplia variedad de funciones necesarias para complejos procesos de prueba de API.

Conjunto de características del Everest

A día de hoy, Everest tiene un conjunto básico de sistemas funcionales para realizar pruebas API efectivas. En primer lugar, Everest admite la verborrea de API más común (OBTENER, POST, PUT, DELETE y PATCH), cobertura suficiente para la mayoría de las API que pueden venir a través del sistema.

Como solución de prueba de API, el método de consulta es el elemento más importante del gran sistema. Everest se centra principalmente en la creación de solicitudes , con soporte para encabezados de solicitud, parámetros de consulta, resaltado de sintaxis y administración de pares clave-valor. Además, admite una amplia variedad de códigos de estado HTTP , tipos de contenido complejos, valoración de tiempo y tamaño y un visualizador JSON .

Uno de los principales enfoques de Everest es la mejora de la calidad de vida en el entorno de pruebas API. Una gran parte de esto es el hecho de que Everest tiene una función de recopilación de historial , lo que permite que las consultas anteriores se registren a lo largo del tiempo y que se ejecuten búsquedas en estas solicitudes, ubicando datos en el destino, encabezados, método, cuerpo y archivos agregados a la solicitud. Everest tiene lo que llama un sistema de “clasificación inteligente” para marcar la relevancia de estos resultados de búsqueda, mejorando aún más ese proceso.

Everest también admite múltiples pestañas en la aplicación, utilizando pseudo-cambio de pestaña para permitir que se realicen muchas pruebas de API. Puede almacenar datos al mismo tiempo mientras mantiene una huella de memoria baja . Esto significa que muchas solicitudes complejas se pueden manejar en la misma vista sin solicitudes de memoria masivas, lo que tradicionalmente es un problema para las soluciones de prueba de API, que a menudo se enfocan en un solo comando o solicitud a la vez.

Cumbre

Una de las cosas que hace que Everest sea único es su servidor de sincronización llamado Summit . En esencia, Summit es simplemente un sistema de sincronización que permite el almacenamiento en la nube , pero en la práctica, hace más. Summit proporciona una API de extensión que permite un mayor apalancamiento y funcionalidad, produciendo un valor único en el sistema Everest. Por ejemplo, Everest cita ejemplos como la sincronización de datos con Google Drive o la visualización de datos de respuesta de forma estructurada: esta API de extensión permite una gama más amplia de transformaciones e interacciones de lo que sería posible de otra manera.

Además, Summit proporciona una solución de servidor simulado local que permite la creación y prueba de servicios RESTful utilizando puntos finales personalizados. Esto, junto con la API de extensión, permite que Everest realice pruebas en tiempo real, iterando sobre los puntos finales desarrollados en cada paso del desarrollo. Juntos, Everest y Summit se elevan mutuamente a alturas más elevadas de las que logran por sí mismos, por esa razón, deben considerarse como una unidad singular.

Pros

El Everest y, por lo tanto, Summit, tienen argumentos bastante sólidos a su favor. En primer lugar, como Everest está escrito en Java , es liviano , incluso en comparación con soluciones similares en otros lenguajes. Es un recurso ligero debido a este hecho, lo que lo hace ideal para pruebas móviles o de bajo consumo.

Más concretamente, debido a que Everest está basado en Java, esto significa que es altamente utilizable en una amplia variedad de sistemas: miles de millones de dispositivos en todo el mundo ejecutan alguna versión de Java, lo que significa que hay muchas posibilidades de que cualquier dispositivo enfrentado al Everest lo haga. ser capaz de ejecutarlo.

Si bien es menos importante que los detalles técnicos, la capacidad de personalizar Everest es bastante impresionante. Muchas herramientas son difíciles de usar simplemente por su interfaz de usuario y sus opciones de diseño. Ser capaz de cambiar esas opciones a nivel de usuario generalmente conduce a una mejor experiencia de usuario.

Hablando de la experiencia del usuario, la presencia de Summit es un gran beneficio para usar Everest frente a otras soluciones. Poder sincronizar el contenido con los proveedores de la nube es excelente y, con ese fin, Summit parece una gran solución. Sin embargo, la historia más importante aquí es la presencia de una solución de servidor simulada, que puede hacer que las pruebas sean más rápidas desde el primer momento.

Contras

Eso no quiere decir, por supuesto, que el Everest sea perfecto. En términos generales, mientras que la apariencia del subprograma es personalizable, la interfaz de usuario, en general, tiene algunos problemas de diseño. Es posible que esto se haya aislado del entorno de prueba utilizado, pero la interfaz de usuario puede parecer un poco tosca.

También se deben tener en cuenta los problemas más pequeños de UX, como la forma en que se maneja el historial. El historial puede ser útil, y poder buscar en el historial es genial, pero cada consulta se registra, lo que da como resultado un área demasiado detallada . Limpiar esta área no es una función que se aclare abundantemente y, de hecho, hacerlo requiere eliminar archivos específicos en la carpeta generada al ejecutar por primera vez el subprograma. Pequeños problemas de experiencia de usuario como este son frecuentes durante toda la experiencia.

Dicho esto, estas desventajas son significativamente menos impactantes que las ventajas mencionadas anteriormente. Mantener sus expectativas en un nivel apropiado también puede ayudar; esta es esencialmente una solución en desarrollo, y debido a que aún es relativamente temprano en ese desarrollo, sus ofertas aún tienen que madurar.

Un flujo de trabajo básico

En este ejemplo, usaremos Everest para llamar a una API meteorológica . Primero, necesitamos descargar y ejecutar Everest. Everest requiere Java Runtime Environment (JVM) para funcionar, por lo que si el cliente en cuestión no lo tiene, es un requisito previo para la instalación. Una vez que se descarga Everest, al iniciar el archivo .jar aparecerá esta interfaz:

Esta es la interfaz básica dentro del Everest. A la izquierda de la pantalla, puede ver el panel del historial , que rastrea todas sus consultas a lo largo del tiempo y permite buscar estas consultas. En el panel superior, podemos ver el generador de consultas y las diversas subáreas dentro del motor de consultas donde podemos establecer parámetros, pasar tokens de autorización y definir el contenido del encabezado y el cuerpo.

Si hace clic en "OBTENER" en el generador de consultas, aparecerá el siguiente menú:

Este menú contiene toda la verborrea admitida actualmente y es el área principal en la que se crean las consultas. Para nuestros propósitos, simplemente vamos a realizar una solicitud GET al punto final base para probar que, de hecho, está en funcionamiento. Podemos hacer esto ingresando el punto final de la API en el generador de solicitudes GET. La salida, formateada como JSON, se ve así:

Aquí, podemos ver un resultado simple de nuestra consulta básica. Un código 200 nos permite confirmar que la API está activa y respondiendo al tráfico. En esta respuesta básica, podemos ver algunos de los elementos clave con fines de prueba. Si bien esto se ha puesto en formato JSON, el menú desplegable para formatear permite algunas opciones interesantes, que incluyen texto sin formato, JSON, XML y HTML. También podemos ver el tamaño de la salida - en este caso, 22 Bytes - así como el tiempo de respuesta - 1,701 milisegundos en este caso.

Ahora hagamos una solicitud más compleja:

Aquí, hemos realizado una solicitud (por recomendación de la documentación de la API) para sondear la API para conocer el clima en una coordenada GPS determinada; esta solicitud se traduce aproximadamente a Linn, Kansas, EE. UU. Aquí podemos ver la parte inferior de la respuesta de la API: tenemos una declaración de la ubicación, el valor del clima, las propiedades del área en cuestión, las propiedades y la geometría de los datos de referencia, y más.

Aquí es donde podemos comenzar a ver datos más significativos sobre la prueba de respuestas individuales: podemos ver si la API respondió de manera demasiado detallada o si el tamaño es demasiado grande. Podemos probar los fallos de seguridad averiguando la suma total de la salida de datos, o incluso ver si podemos realizar un sondeo de identificación masivo, lo que puede, en algunos casos, ser algo con una tasa limitada en lugar de algo de acceso público fuera de consultas específicas.

Preguntémosle al Creador

Nos comunicamos con Rohit Awate para comprender mejor sus motivaciones detrás del desarrollo de Everest y Summit. Parece que una gran motivación fue crear un entorno de pruebas más ajustado.

“La motivación principal detrás del Everest fueron las cifras de uso de memoria de Postman. Estaban consistentemente en el rango de 700-800 MB. No soy un gran admirador de Electron y el peso que conlleva. Pensé que podía hacerlo mejor y por eso comencé a construir el Everest ".

En lo que respecta a la conciencia de la comunidad, Rohit reconoce que JavaFX puede haber sido una elección de lenguaje controvertida, pero cree que vale la pena invertir tiempo en aprender, ya que es muy ligero.

"De las discusiones que he tenido en línea, la gente encuentra que JavaFX es una opción controvertida gracias a la notoriedad de Java por ser pesado, pero lo había usado para un par de proyectos antes y era más liviano que Electron".

Pensamientos finales

Everest y Summit tienen muchas ventajas como par de soluciones: la aplicación liviana utiliza bibliotecas de software ubicuas para hacer lo que hace, y lo hace bastante bien.

Si bien persisten los problemas de UX más pequeños, el hecho de que esto aún sea relativamente temprano en su desarrollo debe usarse como contexto para tales deficiencias. Rohit nos recuerda que Everest es "todavía un trabajo en progreso", pero su objetivo es "lanzar una versión estable junto con Summit a finales de este año". Hablando de Summit, Rohit también nos actualizó con planes futuros para desechar el código Node / Express en favor de Golang.

En última instancia, Everest es una solución bastante útil y poderosa por sí sola: la adición de Summit agrega la promesa de una mayor funcionalidad en la nube y un régimen de prueba que es bastante útil para cualquier probador de API RESTful.

¿Qué opinas del Everest? ¿Hay alguna otra herramienta de prueba de API que prefiera sobre Everest y Summit? ¡Háganos saber en los comentarios a continuación!

Publicar un comentario

0 Comentarios