Un adaptador de correo electrónico evita que los casos de prueba dependan del formato de respuesta de un solo proveedor. Debe exponer un contrato pequeño mientras conserva suficiente información para diagnosticar fallas.
Definir cuatro operaciones
- Prepare: establecer un destinatario sintético permitido y registrar el contexto de la prueba.
- Wait: encontrar un mensaje que coincida con el destinatario, propósito y ventana de solicitud dentro de un plazo.
- Read: obtener el contenido necesario para la aserción sin registrar secretos.
- Clean up: eliminar los artefactos de prueba donde sea posible y registrar cualquier limpieza incompleta.
Devolver resultados distintos
| Resultado | Significado |
|---|---|
| Matched | Un mensaje satisface las reglas de correlación de esta prueba. |
| Timed out | No se observó ningún mensaje coincidente antes del plazo. |
| Access rejected | No se pudo validar la credencial o el acceso al buzón. |
| Provider unavailable | El servicio de buzón no pudo completar la operación. |
Probar el adaptador de forma independiente
Utilice fixtures para comprobar la paginación, resultados vacíos, reintentos, respuestas malformadas y cancelación. Mantenga una pequeña verificación de integración en vivo con límite de velocidad para el comportamiento que los fixtures no pueden establecer. Siga el contrato de API actual del proveedor en lugar de raspar la interfaz del buzón.
Mantener las aserciones del producto por encima del adaptador
La prueba de la aplicación debe decidir si un mensaje de bienvenida tiene el destino correcto o si un flujo de verificación cambia el estado previsto. El adaptador no debe declarar silenciosamente esos resultados de negocio como exitosos solo porque llegó un correo electrónico.
Consulte la documentación de la API CleanTempMail actual antes de implementar su adaptador, incluidos la autenticación y los límites de uso.