Nuestro primer test para la API

En esta clase hacemos nuestro primer test para la API - el más básico y el más útil para empezar: comprobar que el endpoint de /jobs responde correctamente.

Además, verás algo clave: los tests no son solo para “cumplir” - sirven para detectar bugs reales, incluso esos que se te cuelan sin darte cuenta.

Qué vamos a testear primero

Arrancamos por lo típico:

• Llamar al endpoint /jobs
• Comprobar que devuelve status 200
• Comprobar que la respuesta contiene una lista de trabajos (un array)

La idea es tener una base sólida antes de meternos a testear filtros, validaciones, POST, PUT, PATCH, etc.

Estructura del test con Node

En el vídeo se usa la estructura clásica con describe para agrupar tests y assert para hacer comprobaciones. Algo así:

import assert from 'node:assert/strict'
import { describe, test } from 'node:test'

describe('GET /jobs', () => {
  test('debe responder con 200 y un array de trabajos', async () => {
    const response = await fetch('http://localhost:1234/jobs')
    assert.strictEqual(response.status, 200)

    const json = await response.json()

    // Primera versión (fallará si no devuelve directamente un array)
    assert.ok(Array.isArray(json), 'La respuesta debe ser un array')
  })
})

assert.strictEqual vs assert.ok

• assert.strictEqual(a, b) exige igualdad estricta (como ===)
• assert.ok(valor, mensaje) exige que el valor sea truthy y te deja un mensaje personalizado si falla

En el vídeo se ve cómo ese mensaje ayuda un montón a entender el fallo rápidamente.

El primer fallo: no era un array

El test fallaba porque la API no devolvía un array directo, sino un objeto con la lista dentro, en algo tipo data. Así que se ajusta el test para mirar donde toca:

const json = await response.json()
assert.ok(Array.isArray(json.data), 'La respuesta debe ser un array en json.data')

Y con eso, el test pasa. Primer paso completado.

El siguiente test: filtrar por tecnología (y aparece el bug)

Después se intenta testear el filtro por tecnología, por ejemplo:

/jobs/technology/react

Se prepara una aserción del estilo:

“cada trabajo debe incluir la tecnología por la que estoy filtrando”

Pero aquí pasa lo interesante: el test revienta con errores tipo cannot read properties of undefined (reading includes), y al tirar contra el endpoint se ve que devuelve 500.

Conclusión: teníamos un bug real en la API y no lo sabíamos hasta que el test lo dejó en evidencia.

Lección importante: ojo con tests generados por IA

En la clase comentamos algo muy realista: la IA te puede ayudar a arrancar, pero:

• puede inventarse nombres de campos (tech vs technology)
• puede asumir estructuras que no existen (job.tech cuando era data.technology)

Así que el test se corrige revisando la respuesta real de la API.

Ejecutar tests cómodamente en el editor

Un tip práctico: el editor muestra botones tipo “play” para ejecutar tests individuales o todos, y eso te da feedback rapidísimo sin estar lanzando comandos todo el rato.

Ejecutar tests en modo watch y arreglar el bug más rápido

Aquí viene el combo ganador:

• activas modo watch para que los tests se vuelvan a ejecutar al guardar cambios
• usas el error del test para ir directo al archivo/línea del problema (por ejemplo en el modelo Jobs)

Cuando se corrige el acceso a la propiedad correcta (de job... a data... según la estructura), los tests vuelven a pasar.

Por qué esto es vital al refactorizar

La moraleja final es oro:

• si quieres refactorizar o tocar código con confianza
• necesitas una red de seguridad que te diga “no has roto nada”
• y eso te lo dan los tests

Sin tests, refactorizar es como cambiar una rueda con los ojos cerrados. Con tests, es más bien un pit stop.

Lo que hemos aprendido

• Crear un primer test de integración para un endpoint GET
• Usar assert.strictEqual y assert.ok con mensajes útiles
• Ajustar el test a la estructura real del JSON de la API
• Detectar un bug real (500 en el filtro por tecnología) gracias a los tests
• Ejecutar tests desde el editor y usar modo watch para iterar rápido
• Por qué testear te permite refactorizar sin miedo

Si ya has llegado hasta aquí, el siguiente paso está clarísimo: vamos a añadir validaciones de Zod para validar los datos de entrada de nuestra API y mejorar la calidad de nuestro código.