Автоматизация интеграционных тестов Twilio с помощью тестовых учетных данных

В этой статье я покажу, как использовать тестовые учетные данные для создания автоматизированных интеграционных тестов для вашего приложения. В примерах я буду использовать фреймворк модульного тестирования Visual Studio, но принципы применимы к любому фреймворку для тестирования.

Тестовые учетные данные состоят из двух частей. Во-первых, они предоставляют второй идентификатор учетной записи (Account Sid) и токен аутентификации (Auth Token), которые можно использовать для аутентификации запросов к Twilio REST API. При использовании этих данных Twilio выполняет запрос в режиме симуляции, но при этом проверяет все входные данные так, как если бы вы использовали реальные учетные данные.

Найти тестовые учетные данные можно в разделе Dev Tools на панели управления Twilio.

Вторая часть тестовых учетных данных — это набор специальных телефонных номеров, которые заставляют Twilio возвращать определенные сообщения об ошибках. Использование этих номеров позволяет тестировать части вашего приложения, обрабатывающие различные ошибочные ситуации, которые могут возникнуть при отправке SMS, инициализации звонка или покупке телефонного номера.

Начнем с настройки тестов, проверяющих отправку SMS-сообщения. Для демонстрации я создал простой класс *Message*, который инкапсулирует SMS-сообщение, отправляемое через Twilio API, а также логику взаимодействия с этим API.

Код класса *Message* довольно простой и использует библиотеку-помощник Twilio для C# для вызовов REST API. Если вас интересует полный код класса, загляните на мою страницу. В этой статье я сосредоточусь на двух частях класса: методе *Send* и свойстве *Status*.

Обычно разработчик, использующий класс *Message* в своем приложении, видит только один метод *Send* без параметров. Это связано с тем, что класс ищет учетные данные для аутентификации в Twilio API в конфигурационном файле. Однако при выполнении тестов мне нужно использовать тестовые учетные данные Twilio, и я не хочу хранить их в этом конфигурационном файле.

Существует множество способов внедрения значений в класс, но в данном случае, чтобы позволить моим тестам внедрять тестовые учетные данные, сохраняя их изолированными внутри тестового проекта, я создал внутреннюю перегрузку метода *Send*, принимающую Account Sid и Auth Token.

Чтобы мои тесты могли видеть этот внутренний метод, мне нужно установить атрибут InternalsVisibleTo.

Теперь, когда я могу использовать правильные учетные данные в тестах, я могу протестировать отправку сообщения.

Часть класса *Message*, которую я хочу протестировать в интеграционных тестах, — это свойство *Status*, доступное только для чтения и сообщающее текущий статус сообщения. Изначально свойство *Status* имеет значение *Unsent*, но после вызова метода *Send* класс *Message* автоматически изменяет значение этого свойства в зависимости от результата отправки сообщения.

Ниже приведен тест, который я написал для проверки значения свойства *Status*:

Тест утверждает, что свойство *Status* будет равно *Success*, что указывает на успешную отправку сообщения в Twilio и получение успешного ответа. В данном случае я знаю, что запрос к Twilio завершится успешно, потому что значение переменной *TO_NUMBER* — это корректный 10-значный номер телефона, который Twilio правильно проверит.

Теперь протестируем случай с ошибкой. Допустим, клиент предоставил номер стационарного телефона, который, очевидно, не может принимать текстовые сообщения. В этом случае при попытке отправить сообщение Twilio вернет код ошибки, и я хочу убедиться, что мое приложение обрабатывает это корректно. Ниже приведен тест, проверяющий этот сценарий:

В данном случае я передаю статическую строку *NONMOBILE_FAIL_TO_NUMBER* в метод создания. Значение этой переменной — +15005550009, один из специальных номеров, предоставляемых Twilio, который заставляет Twilio вернуть ошибку 21614 — ошибку, возникающую при попытке отправить тестовое сообщение на номер, не поддерживающий SMS. Для успешного прохождения теста я проверяю, что значение свойства *Status* будет равно *Fail*.

До сих пор я создавал тесты, позволяющие проверять отправку различных номеров получателя в Twilio API, но что насчет номеров отправителя? Нередко возникает необходимость разрешить пользователям указывать номер, с которого будет отправлено сообщение. У Twilio есть специальные номера для тестирования ошибочных ситуаций, связанных с некорректными номерами отправителя.

В следующем тесте предпринимается попытка отправить сообщение с номера, не принадлежащего вашему аккаунту Twilio:

Признаю, что все эти тесты довольно простые. Если бы я хотел сделать их более полными, одним из вариантов было бы изменение класса *Message* для предоставления дополнительной информации об ошибках, такой как код ошибки Twilio и сообщение, а затем изменение тестов для проверки этих свойств в дополнение к свойству *Status*.

Теперь создадим тест, симулирующий инициацию исходящего телефонного звонка через Twilio REST API. Как и в случае с отправкой SMS, для демонстрации инициации исходящего звонка я создал простой класс *PhoneCall*, инкапсулирующий данные и логику, необходимые для запроса к Twilio API для инициации исходящего звонка.

Как и в тестах SMS, этот тест проверяет свойство *Status*.

Для симуляции ошибки я передам другой специальный номер, предоставленный тестовыми учетными данными Twilio, на этот раз симулируя звонок на международный номер, на который у меня нет прав звонить.

Как и в тестах SMS в предыдущем разделе, я могу создавать тесты для симуляции корректных и некорректных номеров отправителя.

Наконец, рассмотрим, как тестовые учетные данные могут помочь симулировать покупку новых телефонных номеров через Twilio API. Для тестирования я создал фиктивный объект *Customer* с методом *BuyNumber*. Вызов этого метода отправляет запрос к Twilio API для добавления нового входящего телефонного номера в мой аккаунт Twilio, устанавливает свойство *PhoneNumber* класса *Customer* в этот новый номер и возвращает логическое значение, указывающее на успех или неудачу покупки номера.

Для создания теста я передаю тестовые учетные данные во внутреннюю перегрузку конструктора *Customer*, а затем проверяю, что метод вернул *True* и что свойство *PhoneNumber* равно ожидаемому номеру.

В приведенном выше тесте я проверяю покупку конкретного телефонного номера, но Twilio API также позволяет приобретать новый номер, указав только код города. В этом случае Twilio выберет случайный номер в этом коде.

Однако в некоторых кодах городов, таких как манхэттенский код 212, телефонные номера могут быть дефицитными и недоступными. Тестовые учетные данные позволяют симулировать попытку покупки номера из кода города, в котором нет доступных номеров, передав специальный код города:

В данном случае переменная *AREA_CODE* содержит значение 533, которое указывает Twilio симулировать попытку покупки номера из кода города без доступных номеров.

Тестовые учетные данные Twilio — это удобный способ создания интеграционных тестов для вашего приложения без риска повлиять на ваш аккаунт. Они также отлично подходят для того, чтобы убедиться, что в вашем приложении учтены все возможные ошибочные ситуации.

Полный код этой статьи можно найти на моей странице GitHub, и я буду рад вашим вопросам и комментариям. Свяжитесь со мной в Twitter по адресу @devinrader или по электронной почте devin@twilio.com.