¿Cómo probarías una API de creación de pedidos?

Respuesta directa

Qué debe cubrir una buena respuesta

Cómo funciona

Probar un endpoint de escritura empieza por su contrato y sus efectos. Las pruebas de contrato cubren la forma de la solicitud y respuesta exitosas, cada regla de validación con valores límite y el esquema de error para cada fallo. Las de seguridad cubren autenticación ausente o inválida y, más importante, un usuario válido intentando crear un pedido para otra cuenta. Las de negocio cubren totales, impuestos, descuentos y reserva de stock contra fixtures conocidos. Las de fiabilidad cubren idempotencia con clave repetida, dos solicitudes concurrentes por la última unidad de stock, un timeout del proveedor de pagos y un fallo de base de datos a mitad de transacción para confirmar que nada queda a medias. Por último, los eventos emitidos y las filas persistidas se afirman directamente, y una prueba de carga comprueba la latencia al volumen esperado.

Ejemplo

La suite envía un pedido válido y afirma 201, la cabecera Location y la fila persistida; envía cantidad cero y precio negativo y afirma 422 con errores por campo; repite la misma clave de idempotencia y afirma el mismo ID de pedido; lanza dos pedidos concurrentes por un único artículo restante y afirma que exactamente uno tiene éxito; simula un timeout del proveedor de pagos y afirma que el pedido queda pendiente sin decrementar stock; y comprueba que se publicó un evento order.created con el payload correcto.

Errores frecuentes

• Probar solo el camino feliz y los errores de validación obvios.
• Saltarse las pruebas de autorización porque la autenticación está cubierta.
• No probar nunca la concurrencia y publicar un bug de sobreventa.

Una estructura útil para responder

Responde desde tu propia experiencia.

No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.