Каждая фича отправки писем поставляется с лимитами: лимиты на пользователя против спама, лимиты на ящик для защиты входящих, квоты провайдера для защиты репутации. Инженерный вопрос никогда не в том, существуют ли лимиты, — а в том, правильно ли они себя ведут при достижении: чистые ошибки, честные заголовки Retry-After и пользовательское уведомление, которое говорит, что случилось и когда сбросится. Тестировать это на реальных пользователях — хороший способ потерять реальных пользователей. Свежие одноразовые ящики делают всю поверхность тестируемой, не беспокоя никого.
Разложите лимиты до того, как тестировать их
Вы не можете делать проверки против лимитов, которые никто не записал. Сначала инвентаризация:
- Лимиты на ящик: максимум писем на ящик за окно.
- Лимиты на аккаунт: письма верификации или сброса в час на пользователя — поток сброса пароля то место, где это всплывает чаще всего, он разобран в статье как тестировать письма сброса пароля.
- Лимиты на IP и на тенанта: ограничения уровня организации или инфраструктуры.
- Квоты провайдера: собственные троттлы вашего отправляющего провайдера, чьи ошибки ваше приложение должно переводить, но никогда не протекать наружу.
Для каждого запишите из конфигурации или кода: окно, лимит, действие при нарушении — очередь, отказ с 429 или непростительное молчаливое отбрасывание — и должно ли уходить письмо-уведомление. Эта таблица станет вашим чек-листом проверок.
Workflow тестирования лимитов
1. Готовьте свежий ящик на прогон. [Создайте временный ящик](/) или подготавливайте через API, как описано в статье временная почта для QA-тест-аккаунтов. Свежее состояние важно: остаточные счётчики — главный источник путаных результатов. 2. Найдите реальный лимит. Читайте его из конфигурации. Если он не настраивается, зондируйте до изменения поведения, затем подтвердите границу отправками ровно-в-лимите и лимит-плюс-один. 3. Запустите контролируемый всплеск. Бейте по эндпоинту в плотном цикле, записывая каждый ответ: статус, заголовки, тело. Вам нужен первый троттленный ответ и доказательство, что предыдущие были чистыми. 4. Проверьте семантику 429. Правильный код статуса — не 500 и не 200, за которым ничего не следует, — машиночитаемый Retry-After, совпадающий с фактическим окном, стабильный парсимый код ошибки для клиентов и никаких частичных отправок: в очереди или отказано, никогда оба сразу. 5. Проверьте письмо-уведомление. Там, где дизайн говорит уведомлять пользователя — квота приближается, квота превышена, — проверьте, что письмо приходит во временный ящик, называет лимит и время сброса и соответствует реальности. 6. Проверьте восстановление. После истечения окна отправка должна снова работать без ручной расшивки, а уведомление о снятии лимитов, если вы его отправляете, должно сработать ровно один раз. 7. Повторите со спокойным трафиком чуть ниже лимита на несколько окон; следующий раздел объясняет, зачем.
Прототипировать цикл быстрее в песочнице API, а приёмник вроде тестировщика вебхуков ловит прибытие уведомлений без лага опроса.
Всплеск против ровного потока: почему нужно тестировать оба
Алгоритмы рейт-лимитинга — тоже алгоритмы, а у алгоритмов есть форма. Лимитер с фиксированным окном ведёт себя прилично под ровным потоком, но сбрасывает весь бюджет на границе окна — два всплеска, стоящие поперёк границы, могут фактически удвоить лимит. Token bucket поглощает всплески до размера корзины, затем плавно троттлит. Скользящее окно честнее, но дороже в проверке. Протестируете одну форму трафика — проверите один режим, а остальные выпустите непроверенными. То же с уведомлениями: всплеск-тест показывает, сработает ли письмо о превышении один раз, а ровный тест раскрывает, предупреждаете ли вы о каждой отклонённой отправке или раз в окно.
Что проверять
- Статус и заголовки: 429 там, где задокументировано, Retry-After, согласованный с настроенным окном, заголовки рейт-лимитов на месте, если вы их обещаете.
- Стабильность кода ошибки: код ошибки, на который ветвятся клиенты, не должен дрейфовать между релизами; закрепите его тестом.
- Контент уведомления: значение лимита, время сброса и путь forward присутствуют, и время сброса совпадает с наблюдаемым поведением.
- Дедупликация: ровно одно письмо о превышении на окно — а не по одному на каждый отклонённый запрос.
- Гигиена состояния: после восстановления обычная отправка работает, и счётчики не протекают между пользователями или ящиками.
- Никаких молчаливых отбрасываний: каждая отправка доставлена, поставлена в очередь или явно отклонена, и отклонения видны в логах.
Частые ложные срабатывания
- Грязные счётчики: вчерашний тест съел сегодняшний бюджет, лимитер срабатывает раньше, и баг, который вы заводите, — против самих себя. Свежий ящик и свежий аккаунт на прогон.
- Троттлинг провайдера, прочитанный как троттлинг приложения: ошибка квоты провайдера всплывает как ваш 429. Проверьте, какой слой отклонил отправку, прежде чем заводить тикет; логи отправки обычно решают это с одного взгляда.
- Расхождение часов на границах: если тестовая машина и лимитер расходятся во времени, граничные тесты флапают. Ведите проверки по серверным таймстемпам в ответах, где возможно.
- Параллельные наборы, делящие лимит тенанта: два пайплайна, запущенные одновременно, делят один бюджет и оба видят троттлинг раньше ожидаемого.
Частые вопросы
Как тестировать лимиты без реального провайдера в контуре? Направьте staging на sink или мок-провайдер для чистой логики лимитера, но держите хотя бы один путь через реальный конвейер — самим письмам-уведомлениям нужна настоящая доставка для проверки, и здесь одноразовые ящики отрабатывают своё.
Должно ли письмо о превышении квоты приходить в ящик, у которого квота исчерпана? Обычно да, если этот ящик ещё может принимать. Если лимит стоит выше по течению, отправляйте на основной адрес аккаунта. Чего никогда не должно случаться — чтобы уведомление молча блокировалось тем самым лимитером, о котором оно сообщает: исключите системные уведомления из лимитов уровня пользователя и протестируйте это исключение явно.
Какую проверку чаще всего пропускают? Восстановление. Команды долбят троттлинг и никогда не проверяют, что отправка снова работает после окна или что счётчики сбрасываются по ящикам, а не глобально.
Сколько отправок нужно каждому тесту? Достаточно, чтобы пересечь границу с обеих сторон: ровно на лимите, лимит плюс один и один всплеск заметно дальше. Если лимит большой, сделайте его настраиваемым в тестовых окружениях вместо отправки тысяч реальных писем.
Итог
Рейт-лимитинг — фича с пользовательским интерфейсом, и большая часть этого интерфейса — почта: предупреждения о квотах, уведомления о превышении, подтверждения сброса. Тестируйте лимиты как любой другой контракт: всплеском и ровным потоком, с точностью до границы, проверяя коды статусов, заголовки, стабильность формата и контент с таймингом писем-уведомлений. Свежие одноразовые ящики на прогон держат состояние счётчиков чистым, так что вы измеряете лимитер, а не остатки вчерашнего.