Automatización fiable da API de caixa de correo temporal

A versión pouco fiable dunha proba de correo electrónico é curta: crear un enderezo, esperar cinco segundos, ler a primeira mensaxe e esperar que pertenza a esta execución.

A versión fiable segue sendo simple, pero trata a entrega como asincrónica. Crea un enderezo único, rexistra a hora de inicio, realiza sondeos dentro dun prazo, coincide coa mensaxe prevista, valida a acción do produto e informa con suficiente contexto cando algo falla.

Mantén a clave da API fóra da URL

Envía a clave de GPTMail na cabeceira X-API-Key. Non a inclúas nos parámetros de consulta ?api_key=. Os URL gardanse habitualmente no historial do navegador, nos rexistros de acceso, nos sistemas de monitorización e nos datos de referencia.

X-API-Key: YOUR_API_KEY

Almacena a clave no xestor de segredos do teu CI e escóndea nos rexistros. Unha clave pública diaria é cómoda para a exploración; os conxuntos automatizados controlados deberían usar unha clave cuxa cota e uso poidas rastrexar.

Os puntos finais actuais e os exemplos de resposta mantéñense na páxina de documentación da API de GPTMail.

Un enderezo por execución

Xera un novo enderezo para cada proba executábel independentemente. Non derives a corrección dunha caixa de correo compartida por todo o conxunto de probas.

Rexistra o enderezo, o ID do escenario, o entorno e a hora de inicio da proba. Estes valores permítenche rexeitar mensaxes obsoletas e diagnosticar colisións sen rexistrar segredos das mensaxes.

Sondea contra un prazo, non contra unha espera fixa

O tempo de entrega do correo electrónico varía. Unha espera fixa de cinco segundos é tanto un desperdicio cando a entrega é rápida como inestable cando é lenta.

Use un bucle limitado:

deadline = now + 90 seconds
delay = 2 seconds

while now < deadline:
  messages = list inbox
  candidate = newest message matching sender, subject, and start time
  if candidate exists:
    read candidate and continue the product test
  wait delay with a small random jitter
  delay = min(delay * 1.5, 10 seconds)

O prazo forma parte do contrato da proba. Un fluxo de restablecemento de contrasinal pode precisar un límite diferente ao dunha vista previa de boletín masivo. Mantén o límite explícito para que unha dependencia lenta non alargue silenciosamente todo o traballo do CI.

Coincide con precisión

«Primeira mensaxe na caixa de correo» non é un selector útil. Coincide varios sinais:

• o destinatario é igual ao enderezo creado para esta execución;
• a hora de creación é posterior á hora de activación;
• o remitente pertence ao servizo esperado;
• o asunto ou o tipo de mensaxe coincide co fluxo;
• o ID da mensaxe aínda non foi consumido.

Cando o remitente pode emitir varios códigos, selecciona a mensaxe máis recente que coincida. Conserva o seu ID na saída da proba para que os reintentos non o volvan a usar accidentalmente.

Lê só despois dunha coincidencia na lista

A listaxe da caixa de correo debería ser o paso de descubrimento barato. Recupera a mensaxe completa só para o candidato seleccionado. Isto reduce traballo innecesario e evita analizar correos promocionais non relacionados.

Valida o resultado do negocio, non só a presenza dunha cadea de seis díxitos. Envía o código ou abre a ligazón esperada, e logo verifica que a conta alcance o estado correcto.

Xestiona os límites de taxa como un sinal

Se a API devolve unha resposta de cota ou límite de taxa, detén o intento actual e expón a información de reinicio. Reintentos agresivos converten un sinal de capacidade claro en ruído e poden atrasar probas non relacionadas.

Limita a concurrencia no executor de probas, especialmente cando un conxunto crea moitos enderezos ao mesmo tempo. Un pequeno grupo de traballadores é máis fácil de depurar que centos de bucles de sondeo simultáneos.

Limpeza sen ocultar fallos

A limpeza debería executarse despois de capturar a evidencia. En caso de éxito, elimina as mensaxes ou deixa que a retención curta as xestione. En caso de fallo, conserva o enderezo e o ID da mensaxe en artefactos do CI protexidos durante tempo suficiente para a investigación, e despois elimínaos.

Nunca imprimas códigos de verificación, ligazóns privadas ou corpos HTML completos nos rexistros públicos de compilación.

Fai que os reintentos sexan idempotentes

Reintenta a proba como unha nova execución con un novo enderezo. Non supoas que repetir a mesma solicitude contra a mesma conta e caixa de correo comeza nun estado limpo. O remitente pode invalidar códigos antigos, limitar as solicitudes repetidas ou rexeitar invitacións duplicadas.

Se unha solicitude de rede caduca, distingue «non se recibiu resposta» de «a operación non ocorreu». Verifica o estado observable antes de emitir un reintento destructivo.

Informa do punto de fallo

Un fallo útil de automatización identifica unha destas etapas:

1. fallou a xeración do enderezo;
2. fallou a acción do produto antes de encolar o correo;
3. non chegou ningunha mensaxe coincidente antes do prazo;
4. a mensaxe chegou pero o contido non coincidía;
5. fallou a acción de verificación;
6. fallou a limpeza.

Esa clasificación converte un «fallou a proba de correo» intermitente nun traballo que un equipo pode asumir.

Para a matriz de probas máis ampla, le Un plan real de probas de correo. Para o diagnóstico da entrega, usa Correo de verificación que non chega: atopar o paso roto.