Cuando un endpoint exige autenticación y un rol específico, las pruebas end to end deben validar tres escenarios: petición sin token, petición con token de rol incorrecto y petición con token del rol autorizado. Aquí verás cómo estructurar esas pruebas usando seeders, JWT y comparación contra la base de datos para el endpoint de crear categorías.

¿Cómo pruebo un endpoint protegido sin enviar access token?

El primer caso siempre es el más simple: confirmar que la API rechaza peticiones anónimas. La ruta POST /categories está protegida, así que enviar un body sin cabecera de autorización debe responder con un 401 Unauthorized.

El test se arma con supertest, declarando el endpoint, el método y el input data con name e image. Para datos de prueba puedes escribirlos a mano o apoyarte en una librería como Faker.js que genera información demo realista [02:10].

¿Qué retorna un endpoint protegido si no envío token? Devuelve un código HTTP 401, porque el middleware de autenticación corta la petición antes de llegar al controlador.

¿Cómo autentico un usuario admin antes de las pruebas?

La estrategia es loguearte una sola vez y reutilizar el token. Dentro del describe declaras una variable accessToken en el scope del bloque y la asignas dentro de un beforeAll asíncrono que hace login con un usuario conocido del seed [04:30].

Ese token viaja en cada petición mediante .set('Authorization', 'Bearer ' + accessToken). Después del login, el flujo de creación queda así:

• Enviar POST /categories con el token en la cabecera.
• Esperar un status 201 como respuesta.
• Buscar la categoría recién creada con models.Category.findByPk(body.id).
• Comparar name e image contra el input data enviado.

No olvides limpiar la variable en el afterAll para que no contamine pruebas posteriores. Es un detalle pequeño que evita falsos positivos cuando los archivos de test crecen.

¿Por qué comparar la respuesta contra la base de datos?

Validar solo el status code no garantiza que el registro exista. Al consultar el modelo con la primary key devuelta, confirmas que la persistencia ocurrió y que los campos guardados coinciden con los enviados. Es la diferencia entre probar la API y probar el sistema completo.

¿Cómo simulo un usuario con rol customer en los seeders?

Para probar el rechazo por rol insuficiente necesitas un segundo usuario en el seed. En el archivo de Sequelize agregas un registro adicional con email: customer@mail.com, role: customer y un hash generado a partir de customer123 [08:15].

Un truco para mantener el código lineal: resuelve el bcrypt.hash en la misma línea de la propiedad usando await, así evitas declarar variables intermedias para el admin y el customer. El admin queda con password admin123 y el customer con customer123.

Como la primary key es autoincremental, sabes que el admin tiene id: 1 y el customer id: 2. Ese orden te permite escribir los logins de cada bloque sin ambigüedad.

¿Qué pasa si envío un JWT válido pero del rol equivocado? El servidor responde 401 igual que sin token. El JWT se decodifica correctamente, pero el guard de roles bloquea el acceso porque el usuario no tiene permiso administrador.

¿Cómo estructuro el bloque de pruebas para el rol customer?

Duplicas el describe de categorías y lo renombras para indicar que las pruebas corren con un customer user. El beforeAll ahora hace login con customer@mail.com y password customer123, guardando ese token en la variable local del bloque.

Los casos a cubrir son dos:

1. Sin token: debe retornar 401, igual que en el bloque admin.
2. Con token de customer: también debe retornar 401, porque la ruta exige rol administrador.

Este segundo caso es el más valioso. Confirma que tu middleware de autorización no se queda solo en validar la firma del JWT, sino que además revisa el claim de rol antes de ejecutar el controlador.

¿Dónde se define que solo admin puede crear categorías?

En el archivo de rutas de categorías, el POST está envuelto por un middleware que lista los roles permitidos. Si el array contiene solo admin, cualquier otro rol cae en el manejador de error y la respuesta sale como 401 [10:05]. Esa configuración es la que tu prueba está validando indirectamente.

¿Cómo corro las pruebas y qué debería ver?

Desde la terminal ejecutas npm run test:e2e. La salida agrupa los resultados por describe, mostrando primero las pruebas de categorías con admin y luego con customer. Ambos bloques deben pasar: el admin crea exitosamente y el customer recibe 401 en sus dos escenarios.

Este patrón, seed compartido más login en beforeAll por bloque, te deja un flujo dinámico donde agregar un nuevo rol o un nuevo caso solo requiere extender el seeder y duplicar el describe. ¿Cómo organizarías tú las pruebas si tu API tuviera cinco roles distintos? Cuéntame en los comentarios.