Toda a funcionalidade de envio de email vem com limites: limites por utilizador para travar spam, limites por caixa para proteger as caixas de entrada, quotas do fornecedor para proteger a reputação. A questão de engenharia nunca é se os limites existem — é se se comportam corretamente quando atingidos: erros limpos, cabeçalhos Retry-After honestos e uma notificação visível para o utilizador que diz o que aconteceu e quando é reposto. Testar isto contra utilizadores reais é uma boa forma de perder utilizadores reais. As caixas descartáveis novas tornam toda a superfície testável sem incomodar ninguém.
Mapeie os limites antes de os testar
Não pode verificar contra limites que ninguém escreveu. Inventarie primeiro:
- Limites por caixa: máximo de mensagens por caixa por janela.
- Limites por conta: correio de verificação ou de reposição por hora por utilizador — o fluxo de reposição de palavra-passe é onde isto mais aparece, coberto em como testar emails de reposição de palavra-passe.
- Limites por IP e por tenant: limites ao nível da organização ou da infraestrutura.
- Quotas do fornecedor: as próprias limitações do seu fornecedor de envio, cujos erros a sua aplicação deve traduzir, nunca vazar.
Para cada um, registe a partir da configuração ou do código: a janela, o limite, a ação em caso de violação — fila, rejeição com 429 ou a imperdoável perda silenciosa — e se deve ser desencadeado um email de notificação. Essa tabela torna-se a sua checklist de asserções.
O fluxo de teste de limites de taxa
1. Aprovisione uma caixa nova por execução. [Crie uma caixa temporária](/) ou aprovisione por API como descrito em email temporário para contas de teste de QA. O estado limpo importa: contadores residuais são a principal fonte de resultados confusos. 2. Descubra o limite real. Leia-o da configuração. Se não for configurável, sonde até o comportamento mudar e confirme o limite com envios exatamente-no-limite e limite-mais-um. 3. Dispare uma rajada controlada. Bata no endpoint num ciclo fechado, registando cada resposta: estado, cabeçalhos, corpo. Quer a primeira resposta limitada e a prova de que as anteriores estavam limpas. 4. Verifique a semântica do 429. Código de estado correto — não um 500, não um 200 seguido de nada —, um Retry-After legível por máquina que corresponda à janela real, um payload de erro estável que os clientes consigam analisar e sem envios parciais: em fila ou rejeitado, nunca ambos. 5. Verifique o email de notificação. Onde o desenho diz que os utilizadores são avisados — quota próxima, quota excedida — confirme que o email chega à caixa temporária, indica o limite e a hora de reposição e corresponde à realidade. 6. Verifique a recuperação. Depois de a janela expirar, o envio tem de voltar a funcionar sem desbloqueio manual, e uma notificação de limites-levantados, se existir, tem de disparar exatamente uma vez. 7. Repita com tráfego estável pouco abaixo do limite durante várias janelas; a secção seguinte explica porquê.
Prototipar o ciclo é mais rápido no playground da API, e um recetor como o testador de webhooks captura as chegadas de notificações sem atraso de polling.
Rajada versus estável: porque deve testar ambos
Os limitadores de taxa são algoritmos, e os algoritmos têm formas. Um limitador de janela fixa comporta-se educadamente sob um fluxo estável mas repõe todo o orçamento na borda da janela — duas rajadas em torno de um limite podem efetivamente duplicar o teto. Um balde de tokens absorve rajadas até ao tamanho do balde e depois limita suavemente. Uma janela deslizante é mais justa mas mais cara de verificar. Teste apenas uma forma de tráfego e testou um modo e lançou os outros sem verificação. O mesmo se aplica às notificações: um teste de rajada mostra se o email de excedido dispara uma vez, enquanto um teste estável revela se avisa a cada envio rejeitado ou uma vez por janela.
O que verificar
- Estado e cabeçalhos: 429 onde documentado, Retry-After consistente com a janela configurada, cabeçalhos de limite presentes se os prometer.
- Estabilidade do payload de erro: o código de erro sobre o qual os clientes ramificam não pode derivar entre lançamentos; fixe-o com um teste.
- Conteúdo da notificação: o valor do limite, a hora de reposição e um caminho para avançar estão presentes, e a hora de reposição corresponde ao comportamento observado.
- Desduplicação: exatamente um email de excedido por janela — não um por pedido rejeitado.
- Higiene de estado: após a recuperação um envio normal funciona, e os contadores não vazam entre utilizadores ou caixas.
- Sem perdas silenciosas: cada envio é entregue, posto em fila ou explicitamente rejeitado, e as rejeições são visíveis nos registos.
Falsos positivos comuns
- Contadores sujos: o teste de ontem consumiu o orçamento de hoje, o limitador dispara cedo e o bug que regista é contra si próprio. Caixa nova e conta nova por execução.
- Throttling do fornecedor lido como throttling da aplicação: o erro de quota do fornecedor surge como o seu 429. Verifique qual a camada que rejeitou o envio antes de registar o bug; os registos de envio costumam resolver numa olhada.
- Desvio de relógio nos limites: se a máquina de teste e o limitador discordam na hora, os testes de fronteira oscilam. Baseie as asserções em timestamps do servidor nas respostas sempre que possível.
- Suites paralelas a partilhar um limite de tenant: dois pipelines em execução ao mesmo tempo dividem um orçamento e ambos observam limitação mais cedo do que o esperado.
FAQ
Como testo limites de taxa sem um fornecedor real no circuito? Aponte o staging para um sink ou um fornecedor simulado para a lógica pura do limitador, mas mantenha pelo menos um caminho pelo pipeline real — os próprios emails de notificação precisam de entrega genuína para serem verificados, e é aí que as caixas descartáveis ganham o seu lugar.
O email de quota excedida deve ir para a caixa que excedeu a quota? Normalmente, se essa caixa ainda conseguir receber. Se o limite for a montante, envie antes para o endereço principal da conta. O que nunca pode acontecer é a notificação ser bloqueada silenciosamente pelo próprio limitador que reporta — isente as notificações de sistema dos limites de utilizador e teste explicitamente essa isenção.
Qual é a asserção mais frequentemente esquecida? A recuperação. As equipas martelam o limitador e nunca verificam que o envio volta a funcionar após a janela, ou que os contadores são repostos por caixa e não globalmente.
Quantos envios precisa cada teste? Suficientes para atravessar a fronteira dos dois lados: exatamente no limite, limite mais um e uma rajada bem além dele. Se o limite for grande, torne-o configurável em ambientes de teste em vez de enviar milhares de mensagens reais.
Conclusão
A limitação de taxa é uma funcionalidade com interface de utilizador, e boa parte dessa interface é email: avisos de quota, avisos de excedido, confirmações de reposição. Teste os limites como qualquer outro contrato — rajada e estável, fronteira exata, verificando códigos de estado, cabeçalhos, estabilidade do payload e o conteúdo e o timing dos emails de notificação. Caixas descartáveis novas por execução mantêm o estado dos contadores limpo, pelo que o que mede é o limitador, não os resíduos.