Parte uno: para qué sirven en realidad las pruebas y el desarrollo de API con Postman
Una colección es un registro de solicitudes que se puede compartir y ejecutar. Eso la hace excelente para tres tareas: explorar una API que no conoces, documentarla con ejemplos que realmente se ejecutan y entregarle a alguien una reproducción que pueda lanzar por su cuenta. Esas tres merecen hacerse bien y suelen estar infravaloradas.
El error de los equipos no está en usar colecciones. Está en dar por hecho que la colección puede convertirse en la suite de regresión sin que cambie nada más.
Parte dos: los cuatro problemas
Toda suite de API, en cualquier herramienta, acaba topando con los mismos cuatro. Conocerlos de antemano es buena parte del oficio.
Las sesiones caducan
Los tokens expiran a mitad de la ejecución y los fallos parecen errores del producto.
Saca las credenciales de las solicitudes individuales y llévalas al entorno.
Los valores viajan entre llamadas
Una creación devuelve un identificador que la siguiente llamada necesita.
Captúralo, nunca lo dejes fijo en el código, o la suite funcionará exactamente una vez.
El orden importa
La cobertura es un grafo; una colección es una lista.
Un solo fallo temprano se propaga y llena la pantalla de rojos que no tienen nada que ver.
El cuarto es la limpieza. Los registros se acumulan, empiezan a saltar las restricciones de unicidad y las aserciones de paginación se desvían. Borrar por patrón de nombre es seguro hasta que dos ejecuciones se solapan.
Parte tres: las aserciones que vale la pena escribir
Haz aserciones sobre el cuerpo, no solo sobre el estado. Un 200 con una lista vacía donde debería haber un registro es un error que una comprobación de estado da por bueno.
Comprueba que los fallos fallen como deben. Pide algo que no exista y revisa el código y la forma del error. Es habitual encontrar servicios que devuelven un 200 con un error dentro.
Haz aserciones entre endpoints. Si un registro referencia a otro, recupéralo. Los errores interesantes viven entre dos llamadas.
Parte cuatro: cuando la colección ya no basta
La señal es que tus scripts previos a la solicitud se han convertido en un pequeño framework que solo una persona entiende. En ese punto los cuatro problemas son infraestructura tuya y no de tu herramienta, y ese es el momento de mover la cobertura de regresión a un sitio que los trate como parte del producto. TestSprite los resuelve como Auto-Authentication, Dynamic Variables, Dependency Chains y Auto-Cleanup, descritos en la documentación de pruebas de API.
Conserva la colección. Sigue siendo lo mejor que tienes para explorar y documentar.
Parte cuatro y media: los scripts que nadie revisa
Los scripts previos a la solicitud y los de prueba que viven dentro de una colección merecen un momento, porque ahí es donde están los fallos interesantes y casi nunca se revisan.
Son JavaScript, se ejecutan en un orden concreto, modifican variables de entorno compartidas y se guardan dentro de una exportación JSON cuyo diff no resulta útil. Un cambio en un script de renovación de token puede romper cuarenta solicitudes y el pull request muestra una sola línea de JSON modificada. Los equipos lo descubren la primera vez que dos personas editan una colección en la misma semana.
Si tus scripts han llegado al punto en que ese párrafo te suena, la colección se ha convertido en software. El software pide revisión, control de versiones y pruebas propias, que es un lugar extraño al que llegar cuando el objetivo era probar otra cosa.
Parte cinco: haz que se ejecute sin ti
Conecta el repositorio desde el panel y las ejecuciones arrancarán desde el despliegue que ya generas, o bien añade un paso a tu propio flujo de trabajo.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
La misma configuración está disponible en el panel de TestSprite si prefieres no instalar nada en local. El resto de la superficie del CLI está en el repositorio del CLI.
Parte seis: qué hace TestSprite con los cuatro problemas
Cada uno de los cuatro tiene nombre y se resuelve como producto, no como scripts tuyos. Auto-Authentication configura el flujo de inicio de sesión una sola vez y obtiene un token nuevo antes de cada ejecución. Dynamic Variables captura un valor de una respuesta y lo inyecta en la siguiente solicitud. Dependency Chains deduce un orden seguro a partir de lo que cada caso necesita y produce. Auto-Cleanup elimina exactamente los registros que creó una ejecución.
La cobertura parte de API Discovery sobre el servicio en ejecución más la especificación que tengas, y el plan generado incluye las categorías de autorización, manejo de errores y valores límite, que son justo las que la gente se salta.
La ventaja para quien aprendió este tema con colecciones: conservas la colección para explorar y documentar, que es lo que mejor hace, y la suite de regresión deja de ser un cuerpo de JavaScript que mantiene una sola persona.
¿Existe un PDF oficial y gratuito?
Eso lo deciden las editoriales y va cambiando. Esta página es el conocimiento práctico, no una copia de un libro.
¿Debería aprender Postman primero?
Sí. Es la forma más rápida de construir un modelo mental preciso de una API, y esa comprensión se traslada a cualquier otra herramienta.
¿Hace falta que aprenda a escribir los scripts?
Lo suficiente para leerlos. Cuando ya estás escribiendo muchos, esa es la señal de que se te ha quedado pequeña la colección como suite de regresión.
¿En qué orden conviene aprender todo esto?
Envía solicitudes, luego haz aserciones sobre los cuerpos, luego resuelve la autenticación, luego encadena llamadas y, por último, limpia. En los dos últimos pasos es donde la mayoría se detiene y donde está el valor.
¿Basta con Newman para CI?
Ejecuta colecciones en CI sin problema. La pregunta es quién mantiene los scripts que hay debajo, no qué ejecutor los lanza.
Aprende los cuatro problemas, no el menú.
Las pruebas y el desarrollo de API con Postman van sobre todo de sesiones, valores capturados, orden y limpieza. Las colecciones son excelentes para explorar y documentar; cuando los scripts que hay debajo se convierten en un framework, mueve la cobertura de regresión a algo construido para ello.