API- Herramientas de prueba: Una guía basada en ejemplos

 

Para las pruebas de API, existen muchas herramientas que nos permiten realizar las pruebas y recopilar los resultados. En este artículo, me enfocaré en tres herramientas mostrando directamente cómo hacer una solicitud usando la API de Trello.

 

Pero antes de comenzar, dado que vamos a usar la API de Trello, necesitaremos una cuenta, una clave de autorización y un token. Para las pruebas y el desarrollo de API, este es un paso bastante común que se utiliza para medidas de seguridad, ya que a través de las API podemos tener acceso a bases de datos y funcionalidades internas del código que podrían ser explotadas por usuarios malintencionados. Para eso dejare este link con todos los pasos que necesita para comenzar, puede encontrar estos pasos en la introducción de la API justo debajo de la sección «Autorización y autenticación» (lo verá tan pronto como haga clic en el enlace).

 

Una vez que esté todo listo, comencemos con las herramientas de prueba de API.

 

 Terminal OS

 

Por ejemplo, para obtener una respuesta de nuestra API usando el terminal, necesitaremos la línea de comando llamada «curl» que se usa comúnmente en una gran cantidad de software para, adivinó, transferir datos entre sí.

Vamos a agregar el siguiente comando en la terminal del OS:

 

curl –location –request GET ‘https://api.trello.com/1/members/me/boards?key={your-key}&token={your-token} -I’

 

De aquí obtenemos todos los encabezados

 

Y en la parte superior está el código de estado de nuestra respuesta.

Una característica interesante es que podemos guardar la respuesta en un archivo en caso de que la necesitemos más adelante para un escaneo o para validar algunos de sus campos. Esto se puede hacer escribiendo el comando una vez más con una bandera simple

 “-o [name of the file]”. Por ejemplo: “-o test_response.txt”

 

Una vez hecho esto, deberías ver en tu terminal un medidor que indica el progreso de la descarga.

Si prefieres no agregar un nombre al archivo, simplemente agrega la marca «-O» para guardar el archivo con la URL como nombre de archivo.

 

Y finalmente para cuando necesitemos crear, actualizar o eliminar del URL agregamos los siguientes comandos según lo que necesitemos “-X POST” “-X PUT” “-X DELETE” junto a el “ –data-raw ‘{“param”:”value”}’ ”

 

Ahora veamos cómo la próxima herramienta puede manejar estos mismos escenarios y qué características trae a la mesa:

Postman

Con Postman, obtenemos toda la información que necesitamos con un solo clic. Veamos los ejemplos a continuación:

 

 

Tan pronto como enviemos nuestra solicitud, obtenemos más información de la que podemos solicitar. Para empezar, obtenemos la respuesta completa con un formato bonito, por lo que es mucho más legible y no tenemos que formatearlo por nuestra cuenta, luego tenemos el código de estado para saber si la solicitud fue exitosa o no, en este caso, todo salió como se esperaba y obtuvimos un código de estado 200 y también una pestaña dedicada para agregar parámetros y sus valores que se agregan directamente a nuestra URL de solicitud.

 

Obtenemos toda la información que conseguimos del terminal OS con un solo clic, lo que nos ahorra tiempo y esfuerzo para ser más eficientes al probar nuestra API.

 

Con ese ejemplo, hay otras características clave que Postman pone a nuestra disposición, como guardar nuestra solicitud en una colección (conjunto de URL de solicitud guardadas en una carpeta) en la que recuperamos la URL en cualquier momento sin volver a escribirla en la entrada

 

 

También podemos exportar la solicitud para su uso posterior en un informe de prueba o ejecutarla en una herramienta de CI como círculo CI o Jenkins.

 

 

Postman nos da la oportunidad de trabajar múltiples requerimientos en diferentes tablas.

 

 

En caso de que necesitemos obtener la solicitud en un idioma en particular, nos da el fragmento de código para hacerlo haciendo clic en el código en el tipo parámetros.

 

 

Podemos administrar diferentes entornos en los que podemos almacenar diferentes variables, las variables se pueden nombrar como el usuario quiera y asignar los valores, como las partes comunes de la URL de solicitud para que el usuario solo tenga que manejar la solicitud.

 

 

 

Un historial de todas las solicitudes que hemos realizado recientemente para que el usuario pueda volver atrás y hacer la misma solicitud con parámetros específicos o simplemente ejecutarla una vez más.

 

 

Postman tiene una sección dedicada para agregar pruebas con guiones en Javascript.

 

 

Incluye fragmentos de código predefinidos que podemos usar.

 

Una consola donde podemos ver nuestra respuesta HTTP e imprimir mensajes.

 

 

Estas son las que considero las características clave con las que Postman nos permite trabajar para tener una experiencia más fluida mientras realizamos pruebas con API en general.

 

SoapUI

 

Continúemos con el mismo ejemplo:

 

Nuestra primera impresión de SoapUI tan pronto como ingresamos es que nos mostrará el explorador de puntos finales que nos permite realizar la solicitud a nuestra API de Trello como herramientas anteriores, pero en este caso, como la terminal, obtenemos una respuesta de texto sin formato.

 

 

Además, se puede notar que podemos agregar encabezados a nuestra solicitud en caso de que necesitemos autorización, por ejemplo, y que en la parte superior de nuestro texto sin formato tenemos el estado de respuesta.

 

En la parte inferior, podemos ver el JSON sin formato con los datos que necesitamos. Desafortunadamente, desde el mensaje de Endpoint, no podemos hacer que se vea bonito, así que lo que tenemos que hacer es dentro de un proyecto. El primer paso para hacerlo es hacer clic en el botón Guardar solicitud (azul) junto al botón Enviar (verde).

 

 

Configure un nombre para su solicitud para guardarla y haga clic en el botón Aceptar, esta acción creará el proyecto que se mostrará en el lado izquierdo del programa.

 

 

Hacemos doble clic en «Proyecto 1» (puede hacer clic derecho sobre él si deseas cambiar su nombre) y tendrás una descripción general de todos los componentes de tu proyecto, pero por ahora, me centraré en la solicitud. Expandimos la carpeta del proyecto hasta que solicite la solicitud que está en la última capa y hacemos clic en “TrelloAPI”.

 

 

Tan pronto como hagamos clic en el botón enviar solicitud, veremos un mensaje que dice «El contenido que está intentando ver no se puede ver como XML» porque es el valor predeterminado de las múltiples vistas que tenemos para nuestra respuesta, en el lado izquierdo. notarás cuatro pestañas XML, JSON, HTML y Raw.

 

Hacemos clic en JSON y obtendremos la respuesta bastante formateada.

Podemos consultar las otras pestañas cuando corresponda.

SoapUI nos brinda una gran variedad de características que nos permiten aplicar las pruebas de API de manera más eficiente. El primero que me gustaría resaltar es configurar nuestras pruebas en suites de prueba, cada una con sus casos de prueba y pasos de prueba, lo que facilita al Tester agrupar las pruebas en unidades lógicas.

 

Soporte para servicios WSDL y  SOAP

 

Pruebas de carga y seguridad dedicadas como inputs para el testing. 

 

 

 

Desventajas

 

Para esta sección, agregaré aspectos a considerar para cada una de las herramientas asi podrán elegir según su entorno de trabajo y sus necesidades.

 

• OS Terminal

Falta de interfaz de usuario y agarre de la mano. Este es el más obvio, ya que el usuario necesitaría conocimientos previos de los comandos necesarios para enviar las solicitudes y obtener la respuesta en un formato legible. El terminal se puede personalizar para aliviar este problema, pero sería una capa adicional de configuración fuera del objetivo principal de la prueba.

 

• Postman

 

Falta la supervisión de la prueba. Esta funcionalidad faltante puede ser una decepción para muchos desarrolladores o testers en caso de que quisieran confiar en una sola herramienta para trabajar en todos los conjuntos de pruebas.

 

• SoapUI

Curva de aprendizaje. SoapUI es una herramienta poderosa, pero viene con algunos desafíos y una interfaz no tan fácil de usar. El usuario tardará algún tiempo en comprender la estructura del proyecto en función de los diferentes componentes, como conjuntos de pruebas, casos de prueba, afirmaciones y pruebas de carga para aprovechar al máximo la herramienta.

Para Postman y SoapUI, hay algunas características que están detrás de un muro de pago, pero no considero que sea necesariamente una desventaja, ya que esas características son principalmente para trabajar con un equipo de 5 o más personas que necesitan compartir un proyecto. Pero para un usuario individual, las funciones disponibles de forma gratuita son más que suficientes para hacer el trabajo.

Conclusión

Hasta este punto, hemos visto algunas de las funciones de cada herramienta siguiendo un escenario, en este artículo les he hablado de las funciones que no están relacionadas con las pruebas automatizadas, ya que creo que debería ser un tema en sí mismo. Cada herramienta tiene pros y contras comparándolos entre sí, pero todos pueden ayudar al tester dependiendo de los requisitos de la prueba asignada, correspondería al tester decidir qué estrategia seguir con una de estas herramientas.

 

 

Autor:  Manuel Mariñez
Software Testing Engineer  TechAID
Twitter: MarinezBay
Blog: dev.to/mmarinez20