Los correos de pedido son los mensajes transaccionales de mayor riesgo que envía un marketplace. Un correo de restablecimiento de contraseña que falla es molesto; un recibo con el total equivocado es un incidente financiero. Aun así, probarlos es incómodo: cada escenario necesita una cuenta nueva, una compra en un estado concreto y una bandeja que reciba el resultado. Ese es exactamente el tipo de problema que resuelven las bandejas temporales. Este es el flujo que usan de verdad los equipos de QA para cubrir confirmaciones de pedido, recibos, notificaciones de envío, cancelaciones y reembolsos — sin contaminar cuentas reales ni esperar a la logística real.
Por qué los correos de pedido son especialmente difíciles de probar
Cuatro propiedades separan el correo de marketplace de las pruebas de notificaciones corrientes:
- Dependencia de estado. Una notificación de envío solo existe después de que un pedido esté pagado, empaquetado y despachado. Reproducir el estado es la parte difícil, no el correo.
- Dispersión temporal. Las confirmaciones llegan en segundos; las actualizaciones de envío llegan horas o días después, a veces desordenadas. Las pruebas deben tolerar ese hueco.
- Densidad de campos de fusión. Nombres, direcciones, monedas, líneas de artículo, líneas de impuestos, números de seguimiento — las plantillas de pedido interpolan más valores que casi cualquier otro tipo de correo, y cada uno es una superficie de fallo.
- Coste de la entregabilidad. Una confirmación perdida en spam genera un ticket de "¿dónde está mi pedido?" aunque el pedido en sí esté perfectamente.
Prepara una bandeja por escenario
La disciplina central es el aislamiento. Dale a cada escenario su propia dirección desechable: una para checkout de invitado, otra para checkout de comprador registrado, otra para pedidos multi-artículo, otra para cancelación, otra para reembolso. Cuando una confirmación de reembolso no llega, quieres saber de inmediato si se rompió la canalización o si simplemente el correo de otra prueba cayó en la misma bandeja.
Esto refleja el patrón más amplio de correo temporal para cuentas de prueba de QA: sembrar cuentas con direcciones dedicadas, hacer aserciones, desmontar. Los equipos que construyen procesamiento entrante extienden esas mismas bandejas a canalizaciones de eventos, como se describe en correo temporal para pruebas de email con webhooks.
Los cinco correos que todo marketplace debe clavar
Recorre esta lista en orden, porque cada paso depende del anterior:
1. Confirmación de pedido. Llega momentos después del checkout. Compara líneas, cantidades, precios unitarios, impuestos, coste de envío y total final contra el fixture del carrito. Los símbolos de moneda y los separadores decimales se rompen aquí primero en las pruebas de internacionalización. 2. Recibo de pago. El registro orientado a finanzas. Los totales deben coincidir exactamente con la confirmación; un desajuste entre confirmación y recibo es el defecto que los equipos de finanzas escalan más rápido. 3. Notificación de envío. Transportista, número de seguimiento y un enlace profundo que de verdad resuelve a la página de seguimiento del transportista. Ese enlace profundo es el elemento que se rompe con más frecuencia tras cualquier migración del frontend. 4. Confirmación de entrega o cumplimiento. Para bienes físicos, el aviso de entregado; para marketplaces digitales, la licencia o el enlace de acceso. El acceso digital merece el mismo escrutinio que los enlaces de descarga de un solo uso. 5. Correos de cancelación y reembolso. La confirmación de cancelación debe indicar qué se canceló, cuándo se emitió el reembolso y cuántos días puede tardar el banco. Los clientes los leen en su momento de mayor ansiedad; la claridad aquí evita tickets evitables.
Haz aserciones sobre el contenido, no solo sobre la entrega — y conéctalo a tu canalización
"Correo recibido" es la aserción más débil posible. Una suite útil comprueba:
- El asunto y el preheader llevan el número de pedido o un resumen humano, nunca variables de plantilla en crudo.
- Cada campo de fusión se resuelve. Que `${user.firstName}` se filtre a producción es la vergüenza canónica; detéctalo comparando los cuerpos renderizados contra los fixtures.
- Los códigos son extraíbles. Si las confirmaciones llevan códigos de verificación o de acceso, paréalos programáticamente — el analizador de OTP saca los códigos de los cuerpos de mensaje sin arqueología de regex.
- Los enlaces resuelven. Pide cada enlace del correo y afirma que aterriza en la página correcta y en el estado correcto.
- Ubicación, no solo llegada. Una confirmación sentada en spam es, funcionalmente, un correo ausente.
Si tu producto procesa correos de pedido — gestores de gastos, agregadores, automatización de soporte — la bandeja desechable funciona además como punto de ingesta: ejecuta los cinco escenarios y comprueba que los datos estructurados extraídos coinciden con los fixtures. El probador de webhooks verifica el lado de eventos de la canalización. Y como los correos de pedido suelen provocar respuestas, dale al flujo de tickets de soporte adyacente su propia pasada con las mismas bandejas.
Preguntas frecuentes
¿Cuántas bandejas de prueba necesita una suite de correos de pedido? Planifica una por escenario, no una por ejecución: checkout de invitado, checkout registrado, pedido multi-artículo, cancelación, reembolso y actualización de envío es un seis típico. Reutilizar una bandeja entre escenarios hace ambiguos los fallos; una bandeja nueva por ejecución mantiene el historial limpio sin añadir esa ambigüedad.
¿Cómo pruebo correos de envío que llegan días después? Dispara el cambio de estado directamente — marca el pedido del fixture como despachado desde tu admin o tu base de datos — o usa un sandbox de marketplace que te permita avanzar el estado del pedido bajo demanda. Prueba la plantilla más su disparador de estado; nunca esperes a la logística real.
¿Deben ser cancelación y reembolso pruebas separadas? Sí. La cancelación es una intención del usuario; el reembolso es un evento financiero. Pueden dispararse con minutos o un día de diferencia, con plantillas y campos de fusión distintos. Probarlos como un solo escenario oculta qué paso falló cuando un cliente se queja.
¿Puedo ejecutar estas pruebas contra un marketplace real? Evítalo. Los marketplaces de producción cobran comisiones de pago reales, filtran dominios desechables de forma impredecible y tratan las compras de prueba repetitivas como abuso. Mantén la suite en staging o en el sandbox oficial de la plataforma, y reserva producción para una comprobación puntual final de entregabilidad.
Conclusión
El correo de pedido de un marketplace es una máquina de estados, y las bandejas temporales dan a cada estado un punto final limpio y observable. Prepara una bandeja por escenario, recorre confirmación, recibo, envío, cumplimiento y reembolso, y haz aserciones sobre contenido, enlaces y ubicación — no solo sobre la llegada. Mantén la suite en staging y [crea una bandeja temporal](/) la próxima vez que el checkout necesite un testigo.