Testing de Operaciones CRUD

Entendiendo CRUD #

CRUD significa Create, Read, Update, Delete — las cuatro operaciones basicas para almacenamiento persistente de datos. Casi cada endpoint de API mapea a una de estas operaciones:

Testear operaciones CRUD sistematicamente asegura que la API maneje correctamente todo el ciclo de vida de un recurso — desde la creacion hasta la eliminacion.

Testing de Create (POST) #

Tests del Happy Path #

POST /api/users
Content-Type: application/json

{
  "name": "Alice Johnson",
  "email": "alice@example.com",
  "role": "developer"
}

Verificar:

• El status de respuesta es 201 Created
• El body de respuesta contiene el recurso creado con un id generado
• Todos los campos enviados estan presentes en la respuesta
• Los campos generados por el servidor existen (id, createdAt, updatedAt)
• El header Location apunta a la URL del nuevo recurso
• Obtener el recurso via GET retorna los mismos datos

Tests de Validacion #

Tests de Unicidad #

Tests de Limite #

• Longitudes maximas de campos (255 chars para nombre, etc.)
• Caracteres especiales: Unicode, emojis, tags HTML, strings de SQL injection
• Valores minimos: arrays vacios, cantidades cero
• Tamano maximo de payload

Testing de Read (GET) #

Recurso Individual #

GET /api/users/42

Verificar:

• Retorna 200 OK con datos completos del usuario
• Todos los campos esperados estan presentes
• Los tipos de datos son correctos (numero para id, string para nombre)
• Campos sensibles estan excluidos (password, IDs internos)

Coleccion (Lista) #

GET /api/users?page=1&limit=20&sort=name&order=asc

Verificar:

• Retorna array de recursos
• Metadata de paginacion presente (total, page, limit, pages)
• El ordenamiento funciona correctamente
• El filtrado retorna solo recursos que coinciden
• La paginacion por defecto aplica cuando no se envian parametros

Casos Borde #

Testing de Update (PUT / PATCH) #

PUT — Reemplazo Completo #

PUT /api/users/42
Content-Type: application/json

{
  "name": "Alice Smith",
  "email": "alice.smith@example.com",
  "role": "senior-developer"
}

Verificar:

• Todos los campos se reemplazan con nuevos valores
• Campos opcionales omitidos se resetean a valores por defecto o se eliminan
• El timestamp updatedAt cambia
• id y createdAt permanecen sin cambios
• GET despues de PUT retorna los datos actualizados

PATCH — Actualizacion Parcial #

PATCH /api/users/42
Content-Type: application/json

{
  "role": "senior-developer"
}

Verificar:

• Solo cambia el campo especificado
• Todos los demas campos permanecen exactamente como antes
• El timestamp updatedAt cambia

Casos Borde de Actualizacion #

Testing de Delete (DELETE) #

Delete Estandar #

DELETE /api/users/42

Verificar:

• Retorna 204 No Content (o 200 OK con confirmacion)
• GET del recurso eliminado retorna 404
• El recurso ya no aparece en el endpoint de lista
• Los recursos relacionados se manejan correctamente (cascada o proteccion de huerfanos)

Casos Borde de Delete #

Test de Flujo CRUD End-to-End #

El test mas importante es el ciclo de vida completo:

1. POST /users → Crear usuario → Guardar ID
2. GET /users/{id} → Verificar que el usuario existe con datos correctos
3. GET /users → Verificar que el usuario aparece en la lista
4. PUT /users/{id} → Actualizar todos los campos
5. GET /users/{id} → Verificar actualizacion aplicada
6. PATCH /users/{id} → Actualizar parcialmente un campo
7. GET /users/{id} → Verificar que solo ese campo cambio
8. DELETE /users/{id} → Eliminar usuario
9. GET /users/{id} → Verificar 404
10. GET /users → Verificar que el usuario ya no esta en la lista

Este flujo testea persistencia, consistencia y limpieza de datos a lo largo de todo el ciclo de vida.

Relaciones de Datos #

Cuando los recursos tienen relaciones (usuario tiene muchos pedidos), testea:

• Crear recurso hijo con ID de padre valido
• Crear recurso hijo con ID de padre invalido (deberia fallar)
• Eliminar padre con hijos existentes (comportamiento en cascada)
• Obtener padre incluye/excluye hijos segun lo documentado
• Actualizar padre no afecta datos del hijo

Ejercicio Practico #

Usando JSONPlaceholder (https://jsonplaceholder.typicode.com):

1. Ciclo CRUD completo: Crea un post, leelo, actualizalo con PUT, actualizacion parcial con PATCH, eliminalo, verifica la eliminacion
2. Testing de validacion: Intenta crear un post con campos faltantes, tipos incorrectos, valores vacios
3. Testing de relaciones: Crea un post, luego crea comentarios para ese post. Que pasa cuando eliminas el post?
4. Testing de lista: Testea paginacion, filtrado por userId y verifica la estructura de respuesta para GET /posts

Puntos Clave #

• Las operaciones CRUD forman la columna vertebral del testing de API — cada recurso pasa por crear, leer, actualizar, eliminar
• Siempre verifica la persistencia de datos siguiendo POST con GET para confirmar que el recurso realmente existe
• Testea tanto PUT (reemplazo completo) como PATCH (actualizacion parcial) para asegurar que se comportan diferente como se espera
• Los tests de flujo CRUD end-to-end detectan bugs de integracion que tests de operaciones individuales pueden perder
• No olvides los casos borde: recursos inexistentes, entradas duplicadas, eliminaciones en cascada y actualizaciones concurrentes