Te dan un endpoint REST nuevo, POST /users, para crear usuarios. ¿Qué probarías además del caso feliz?

Organizo las pruebas por categorías:

• Caso feliz y persistencia: 201 Created, cuerpo según el esquema y header Location si corresponde. Luego hago un GET o consulto la base para confirmar que se guardó bien.
• Validación: campos obligatorios faltantes, tipos incorrectos, formatos inválidos (email), longitudes límite y campos extra no esperados. Espero 400/422 con un mensaje claro.
• Reglas de negocio: email duplicado → 409; mayúsculas en el email; espacios en blanco al inicio o al final.
• Contrato: validar la respuesta contra el OpenAPI/JSON Schema y verificar Content-Type. Enviar un content-type incorrecto debería dar 415.
• Autenticación y autorización: sin token → 401; token sin permisos → 403; que un usuario común no pueda enviar "role":"admin" (mass assignment).
• Seguridad básica (en entorno de pruebas propio): que la respuesta no exponga la contraseña ni su hash; que los caracteres especiales se manejen sin errores 500 ni stack traces; payloads grandes; rate limiting.
• Robustez: JSON malformado, body vacío y concurrencia (dos requests iguales simultáneas no deben crear dos usuarios).

Ejemplo con pytest:

def test_email_duplicado(api, nuevo_usuario):
    api.post("/users", json=nuevo_usuario)
    r = api.post("/users", json=nuevo_usuario)
    assert r.status_code == 409
    assert "password" not in r.text

Los datos de prueba son únicos por ejecución, para no depender del estado previo, y los automatizo en CI con pytest+requests, REST Assured o Postman/Newman.

Quedarse solo con status codes sin verificar persistencia ni cuerpo, ignorar autorización y fuga de datos sensibles en la respuesta, o escribir tests que dependen de datos fijos y fallan al re-ejecutarse.