Что вы на самом деле тестируете
У потока верификации несколько подвижных частей, и каждая может сломаться независимо. Хорошие тесты покрывают счастливый путь и пути сбоя, потому что именно в обработке сбоев завоёвывается или теряется доверие пользователя.
- Отправка: код генерируется и отправляется для валидного номера.
- Приём и проверка: правильный код принят, сессия повышена.
- Отклонение: неверные, истёкшие и повторно использованные коды отклонены.
- Лимиты: ограничение частоты и задержки повтора ведут себя как задумано.
- Запасной канал: эскалация канала и состояния ошибок отрисовываются корректно.
Используйте тестовые учётные данные провайдера и магические коды
Каждый крупный провайдер даёт способ прогнать поток без отправки реальных сообщений. У Twilio есть тестовые учётные данные и магические номера, имитирующие успех и конкретные ответы-сбои; Vonage, Sinch и MessageBird предлагают режимы песочницы и тестовые номера. Используйте их в локальных и CI-прогонах, чтобы ваш набор тестов никогда не касался реального оператора.
- Twilio: тестовые учётные данные + магические номера, форсирующие успех/невалидность/сбой.
- Другие: API-ключи песочницы и назначенные тестовые номера.
- Держите тестовые и живые учётные данные в отдельных, чётко названных конфигурациях окружения.
Никогда не прогоняйте тесты против живых учётных данных в CI — один баг в цикле может отправить тысячи платных сообщений и привести к пометке отправителя.
Выделите тестовые номера под вашим контролем
Для сквозных тестов, которые действительно доставляют сообщение, выделите принадлежащие вам программируемые номера как тестовых получателей, затем прочтите доставленный код обратно через API сообщений провайдера и подайте его в ваш шаг проверки. Поскольку номера и приложение принадлежат вам, это чистый замкнутый тест вашей собственной системы.
- 1
Выделите тестовый номер
Создайте программируемый номер в аккаунте провайдера, выделенный под тестовое окружение.
- 2
Запустите свою отправку
Вызовите собственную конечную точку регистрации/проверки, чтобы приложение отправило реальный код на тестовый номер.
- 3
Прочтите код через API
Заберите входящее сообщение через API провайдера и извлеките код программно.
- 4
Завершите и проверьте
Отправьте код в вашу конечную точку проверки и убедитесь, что сессия повышена; затем освободите номер.
Автоматизируйте это в CI
Встройте вышеописанное в конвейер, чтобы верификация проверялась на каждой сборке. Используйте мок/песочницу для быстрых модульных и интеграционных тестов на каждом коммите, а реальный замкнутый тест (с принадлежащими вам номерами) оставьте на ночную или предрелизную стадию для контроля затрат.
- Быстрая полоса: мок провайдера или тестовые учётные данные на каждом коммите.
- Медленная полоса: реальная отправка на собственный номер ночью или перед релизом.
- Проверяйте и пути сбоя: истёкшие коды, неверные коды и ответы ограничения частоты.
- Оповещайте о регрессиях задержки доставки, а не только о passed/failed.
Тестируйте доставляемость, а не только логику
Тесты логики доказывают, что ваш код верен; они не доказывают, что сообщения доходят в реальном мире. Периодически отправляйте реальный тестовый трафик на номера у ваших ключевых операторов и стран и измеряйте фактическую долю доставки и задержку, чтобы поймать регрессию маршрутизации или фильтрации раньше пользователей.
Проблемы доставки часто проявляются по стране или по оператору. Ротируйте мониторинг по вашему реальному набору направлений — руководство по доставляемости объясняет почему.