Capítulo 1.5: Pruebas de API a través de Postman

Tiempo de estudio: 50 minutos

---

1. ¿Por qué probamos las API? Verificación previa al lanzamiento

Imagine: antes del lanzamiento de un cohete, los ingenieros realizan pruebas de encendido de sistemas. Si se omite una verificación, ¡la misión podría fallar!

Las pruebas de API son sus pruebas de control:

• ✅ Verificar la operatividad de los "nodos de acoplamiento"

• 🛡️ Detectar vulnerabilidades antes de su uso en combate

• 📊 Asegurarse de que los datos se transmitan sin distorsiones

💡 Analogía espacial: Postman es como una consola de pruebas del Centro de Control de Misiones (CCM) para simular todos los escenarios: "¿Qué pasa si se solicitan datos de un planeta inexistente? ¿Soportará el servidor 1000 solicitudes/seg?"

---

2. Postman: "Centro de Control de Vuelo" para API

Capacidades:

• 📡 Envío de cualquier solicitud HTTP (GET, POST, PUT, DELETE)

• 🔍 Análisis de respuestas (códigos de estado, encabezados, cuerpo JSON)

• 🧪 Escritura de pruebas automatizadas (JavaScript)

• 🌐 Trabajo con variables de entorno (pruebas vs producción)

👉 Descargar Postman

---

3. Primer lanzamiento: Probando la API de planetas

Paso 1: Crear una solicitud

1. Abrir Postman → New → Request

2. Introducir URL: https://api.spacexdata.com/v4/rockets

3. Seleccionar método: GET

Paso 2: Enviar la "señal"

[CCM] -- GET /planets --> [Servidor SpaceX]

Paso 3: Analizar la telemetría: - Estado: 200 OK - Cuerpo de la respuesta (JSON): lista de cohetes con parámetros

[
  {
    "name": "Falcon 1",
    "type": "rocket",
    "active": false,
    "stages": 2,
    "id": "5e9d0d95eda69955f709d1eb"
  },
  {
    "name": "Falcon 9",
    "type": "rocket",
    "active": true,
    "id": "5e9d0d95eda69973a809d1ec"
  }
]

---

4. Esquema: Componentes de Postman

[Espacio de trabajo]
├── Pestaña "Params" (Parámetros de consulta)
├── Pestaña "Headers" (Encabezados)
├── Pestaña "Body" (Cuerpo de la solicitud para POST/PUT)
├── Pestaña "Tests" (Scripts para verificaciones)
└── Panel de respuesta (Estado, Tiempo, Tamaño, Cuerpo)

---

5. Creando un escenario complejo: Lanzamiento de una misión

Prueba: Añadir un nuevo planeta al catálogo

1. Método: POST

2. URL: https://jsonplaceholder.typicode.com/posts (ejemplo)

3. En Encabezados:

    { "Content-Type": "application/json" }
   

4. En Cuerpo (raw → JSON):

   {
    "title": "New Exoplanet Found",
    "body": "Proxima Centauri b shows signs of a stable atmosphere.",
    "userId": 1
    }
   

Verificación automática en Tests:

// Verificación de estado
pm.test("Post created successfully", () => {
    pm.response.to.have.status(201);
});

// Verificación de estructura y datos de la respuesta
pm.test("Response contains the new post data", () => {
    const response = pm.response.json();
    pm.expect(response).to.have.property("id"); // Verificamos que el servidor asignó un ID
    pm.expect(response.title).to.eql("New Exoplanet Found");
});

---

6. Variables de entorno: Tierra vs Marte

¿Cómo probar en diferentes servidores (de prueba/producción)?

1. Crear entornos:
2. Local → http://localhost:3000

3. Production → https://api.nasa.gov

4. En las solicitudes, usar variables:

   {{base_url}}/planets  # Sustituirá la URL actual
   

⚠️ ¡Importante! ¡Nunca pruebe DELETE en un servidor de producción!

---

7. Colecciones: Biblioteca de misiones espaciales

Agrupar solicitudes:

    📂 Colección "NASA"
    ├── GET Planetas
    ├── POST Nuevo planeta
    └── DELETE Planeta (modo de prueba)

Ventajas:

• 🚀 Ejecutar todas las pruebas con un solo botón
• 📤 Exportar/importar configuraciones
• 👨‍🚀 Trabajo colaborativo en equipo

---

8. Automatización: Verificaciones regulares de satélites

Configurar la monitorización de API a través de Postman:

1. Schedule → Cada 2 horas

2. Pruebas:

   pm.test("Satélite en línea", () => {
     pm.response.to.have.status(200);
     pm.expect(pm.response.json().signal).above(50); // Señal >50%
   });
   

3. Notificaciones en Slack/email en caso de fallo

---

Cuestionario para consolidar

1. Postman se utiliza para:

a) Enviar correo b) Probar API c) Crear bases de datos

2. ¿Qué estado esperar al crear un objeto con éxito?

a) 200 OK b) 201 Created c) 404 Not Found

3. ¿Dónde escribir pruebas automatizadas en Postman?

a) Pestaña "Body" b) Pestaña "Tests" c) Pestaña "Cookies"

4. Las variables de entorno son necesarias para:

a) Alternar entre el servidor de prueba y el de producción b) Almacenar contraseñas en texto claro c) Generar datos aleatorios

5. ¿Qué verifican las monitorizaciones regulares?

a) La estabilidad del funcionamiento de la API b) La velocidad de internet c) La actualidad de la documentación

Verificar

---

🚀 Resumen del capítulo: Postman es su "consola de control" universal para probar API. Con él, usted: - Verificará el funcionamiento de los "sistemas a bordo" antes del lanzamiento - Creará una biblioteca de escenarios de prueba - Automatizará la monitorización de servicios espaciales

📌 Ejercicio práctico:

1. Instale Postman
2. Cree una solicitud a la API de SpaceX: GET https://api.spacexdata.com/v4/launches/latest
3. Escriba una prueba que verifique que:
4. El estado de la respuesta es 200
5. El campo name contiene la palabra "Falcon"
6. El tiempo de respuesta es < 500 ms

¡Felicidades por completar el Capítulo 1!

Ha dominado los fundamentos del trabajo con API. ¡En los próximos capítulos construiremos nuestra propia "nave espacial" – una aplicación web que utiliza API espaciales!

🌌 Recursos adicionales:

• SpaceX API Documentation