Postman: Pruebas de API como si fuera un niño [parte II pruebas > requisiciones]

“Lo que es verdad hoy, mañana puede ser una mentira.”

Pimenta Machado

Continuando con la primera publicación, hoy hablaremos sobre la importancia de probar nuestras API y un poco de mi trayectoria de pruebas de API.

Es muy común en mi experiencia REST API preguntar a otros profesionales ejemplos de cómo interactuar con sus APIs. Generalmente, me envían proyectos en SOAPUI o colecciones en Postman donde puedo encontrar una serie de requisiciones para algunas rutas.

Cuando voy a inspeccionar las requisiciones más a fondo, sólo eran eso, requisiciones y nada más.

El problema con las requisiciones es que te dicen cómo enviar algo, no lo que deberías esperar si funciona correctamente, por lo que ni siquiera sabes si realmente está “funcionando”.

Mi camino hasta ahora

Empecé a trabajar con pruebas de API con SOAPUI. La gran ventaja de la prueba en SOAPUI es una serie de componentes, como pruebas SLA, pruebas de respuesta, pruebas de código de estado HTTP, etc.

SOAPUI le da la diferencia entre las requisiciones y las pruebas muy claramente. Las pruebas en SOAPUI se encuentran en un área separada, conocida como Test Suite, donde puede crear Test Steps, Load Tests y Security Tests.

SOAPUI es una buena herramienta para darle una idea de qué tipo de pruebas puede hacer, pero tiene algunos problemas, como:

• La interfaz no es fácil de usar;
• Consumo de memoria con varias pestañas abiertas;

Además de los puntos anteriores, cambié mi herramienta de prueba debido a la dificultad de interactuar con mi equipo en AIS, ellos me contaron acerca de otra herramienta de prueba llamada Postman.

La interfaz de usuario de Postman es más amigable que SOAPUI. Los problemas de memoria de mi computadora también se han detenido.

Sin embargo, no hay componentes de prueba en Postman, debería escribir todas las pruebas en JavaScript. JavaScript no es un lenguaje que me apasione, pero no se puede ignorar en el mundo del desarrollo de software hoy en día.

Otra dificultad que tuve con Postman es que nunca sé si la colección de prueba que he guardado en mi máquina está actualizada porque aún no he encontrado la forma de sincronizarla con mi computadora sin exportarla. Explicaré un poco más sobre esto en la parte de Integración Continua de Postman.

De todos modos, lo que es importante aclarar aquí es por qué deberíamos probar nuestras API.

¿Por qué probar tu API?

Cualquier certeza en un mundo de incertidumbre es un alivio. Saber que algunas premisas son válidas en un escenario dado nos da tranquilidad y seguridad de que no vamos a la dirección equivocada.

Otro problema, como dijo Pimenta Machado, es que lo que es cierto hoy, mañana puede ser una mentira, y en el mundo del desarrollo de software, la frase se ajusta como un guante.

Una simple requisición no lo “notificará” si algo cambia mañana. Hace un tiempo, escribí sobre el porqué probar y para no volverme repetitivo, recomiendo leer la siguiente publicación [versión portuguesa].

¿Qué hemos aprendido hasta ahora?

• Pruebas > Requisiciones;
• Lo que es cierto hoy, mañana puede ser una mentira.

En la próxima publicación, hablaremos más sobre Postman.