Лучшие способы проверить свои бессерверные программы

1656596434 luchshie sposoby proverit svoi besservernye programmy

Бессерверный – это больше, чем модель выполнения облачных вычислений. Это изменяет способ планирования, создания и развертывания программ. Но это также изменяет метод тестирования наших программ.

Знакомьтесь, Алекс. Алекс – обычный разработчик JavaScript, в последнее время сосредоточенный на Node.js.

MtalllczKaCqHXoYLjhWS-dsCuadSW0CSYJ4
Это Алекс

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

W4arHIFaqZutDUYabYBKCAMZsnyVvctmT4G5
Анна и Джефф всегда говорят об этой штуке без сервера

В какой-то момент Алекс и его команда получили новый проект. После некоторого анализа Алекс подумал, что он идеально подойдет для бессерверных. Он представил идею своей команде. Некоторые члены команды были взволнованы, одному это не понравилось, но большинство из них не имело твердого мнения. Поэтому они решили попробовать проект был не слишком большим, а риск был низким.

4SH3bquVOC81aS03e6CJcUwGSvaRHI7illvN
Команда Алекса обсуждает использование бессервера в своем новом проекте

Команда прочла о бессерверности, и они получили идею, как структурировать свое новое приложение. Но никто не был уверен, как они должны вписаться без серверов в общий процесс разработки.

В данный момент их процесс выглядит так:

  1. Они анализируют новенькую функцию.
  2. Для менее сложных функций они начинают с кода, затем его запускают локально и в конце добавляют несколько тестов.
  3. Для более сложных функций создают свою версию TDD: они начинают с тестов, затем пишут код и тестируют его локально.
  4. Когда функция готова, она переходит в инструмент CI, который разворачивает ее в среде тестирования.
  5. Затем QA использует новую функцию для очередного раунда ручного тестирования. Если все смотрится хорошо, программа переходит через CI к производству.
3FiH7yO9EWUI6fIo0JG8IQppAbm-a2AvDfCq
Общий процесс разработки команды Алекса

Они решили начать шаг за шагом, а затем решать проблемы по мере их возникновения.

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

Местное тестирование

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

nS02sQWyNQjiJZN9R71AMMVYZ04rQSku9fes
Первый блокпост: как запустить бессерверное приложение локально?

В зависимости от программы и бессерверного поставщика можно запускать некоторые части программы локально. Для этого вы можете использовать некоторые из следующих инструментов и приёмов:

Конечно, список не полон — инструментов больше, и мы сейчас почти каждый день видим новые инструменты.

Большинство этих инструментов имеют определенные ограничения. Они могут моделировать бессерверные функции и некоторые другие услуги, такие как API Gateway. Но как насчет разрешений, уровня авторизации и других служб?

Локальное тестирование помогает быстро проверить, работает ли ваша функция. Но есть ли лучший способ убедиться, что ваше бессерверное приложение работает должным образом? Да есть. Первый и самый важный шаг: написать тесты.

Алекс и его команда попробовали свою первую функцию локально, и, казалось, она работала. Затем они перешли к следующему шагу.

Автоматизированные тесты

Алекс и его команда только что перешли на Jest для тестирования своих приложений Node.js. Они все еще много используют интерфейс, поэтому хотят использовать те же инструменты для полного стека, когда это возможно. Могут ли они использовать Jest для тестирования бессерверных программ? И что они должны проверить?

fFyCbvZfkRQsbC-Pjse6tUul8djTl6hTstHt
Второе препятствие: как влияет бессерверное влияние на автоматическое тестирование?

После скорейшего расследования они поняли, что могут использовать свои любимые инструменты тестирования Node.js. Jest, Jasmine, Mocha и другие отлично работают с бессерверными.

Что нужно тестировать в программе без сервера?

С помощью своих программ Node.js Алекс и его команда придерживаются трехуровневой пирамиды автоматизации тестирования. Тестовую пирамиду впервые упомянул Майк Кон в своей книге «Успех с помощью Agile».

Как определяет тестовая пирамида, они имеют:

  • Много модульных тестов, потому что они самые дешевые (быстрые для написания и выполнения)
  • Меньше интеграционных тестов, поскольку они дороже, а их выполнение требует больше времени
  • Несколько тестов пользовательского интерфейса, потому что они самые дорогие (нужны инструменты графического интерфейса) и самые медленные в работе

Кроме того, они также имеют ручное тестирование на основе сеанса, которое выполняет их команда QA.

4mPvNp-TQMmpeAofZQdp5xnU4vSNZldSlqHn
тестовая пирамида с ручным тестированием

Как бессерверное влияние оказывает влияние на пирамиду автоматизации тестирования?

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

Уровень модульных тестов не сильно влияет. Юнитные тесты все еще самые дешевые для написания и исполнения, но единицы могут быть меньше.

Уровень интеграционных тестов становится важнее, чем когда-либо, потому что бессерверные программы во многом полагаются на интеграцию. Это тоже дешевле, поскольку иметь бессерверную базу данных только для тестирования – это дешево. Итак, в бессерверной тестовой пирамиде вам нужно иметь больше интеграционных тестов.

Уровень тестов GUI также дешевле и быстрее из-за более дешевой распараллелировки.

Уровень ручного тестирования остается неизменным. Но бессерверный может помочь вам немного улучшить его. Мы рассмотрим подробности этого позже.

j0kvLDW4Tykdab9y8ZQMZ10gBAe81GmDLipn
Бессерверная «тестовая пирамида»

Алексей и его команда наконец-то выяснили, на чем сосредоточиться. Следующая проблема заключалась в том, как написать функцию, чтобы легче их проверить.

Как написать тестируемые бессерверные функции

При написании бессерверной функции вам нужно подумать о таких рисках:

  • Конфигурационные риски Правильная ли база данных и таблица? Или у вас есть права доступа?
  • Риски технического рабочего процесса Вы анализируете и используете входящий запрос как следует? Или вы правильно обрабатываете успешные ответы и ошибки?
  • Риски бизнес-логики Соблюдали ли вы все правила бизнес-логики, которые есть в вашей программе?
  • Риски интеграции Правильно ли вы читаете структуру входящего запроса? Или вы правильно храните заказы в базе данных?

Чтобы подтвердить, что ваша бессерверная функция работает правильно, необходимо проверить все эти риски.

Вы можете проверить любой из них, как и для интеграционных тестов. Но настройка и настройка службы каждый раз, когда вы хотите проверить один из этих рисков, не является оптимальной. Как любит говорить мой друг Александр Симович:

Представьте себе, если тестирование автомобилей проводилось таким образом. Это означало бы, что всякий раз, когда вы хотите проверить один винт или даже зеркало в автомобиле, вам придется собрать, а затем разобрать весь автомобиль.

Чтобы сделать приложение более тестируемым, понятным решением является разбить вашу функцию на несколько меньших.

Один из прекрасных способов сделать это – применить гексагональную архитектуру. к вашим бессерверным функциям.

Гексагональная архитектура, или Порты и адаптеры, является формой архитектуры приложений, способствующей разделению проблем через уровни ответственности. Как объясняет его создатель Алистер Кокберн:

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

Итак, как это касается бессерверных функций?

Поскольку Алекс и его команда пользуются AWS, они получили следующую структуру:

  • Бизнес-логика функций открывает несколько портов (или ожидает мало аргументов). Например, один для входящего события, один для постоянного хранения и один для уведомлений.
  • Они имеют два адаптера для события, запускающего функцию, один для настоящего триггера AWS Lambda, а другой для локального тестирования.
  • Они имеют несколько адаптеров для хранения и оповещений. Например, адаптер DynamoDB и адаптер в памяти.
chFxK8htCl5K2QOkoBOCnXv18f4xCI47okvJ
Гексагональная архитектура функции AWS Lambda

Алекс и его команда были счастливы, что двигаются вперед. Но прежде чем мы пройдем дальше, давайте посмотрим, как шестиугольная архитектура влияет на каждый уровень тестовой пирамиды.

Юнитное тестирование

Юнит-тесты остались прежними. Но проще писать модульные тесты через гексагональную архитектуру. Они могут просто использовать локальный адаптер или макет в качестве адаптера, чтобы проверить функциональный уровень бизнеса изолированно.

Интеграционное тестирование

Интеграционные тесты внесли большую пользу Hexagonal Architecture. Они смогли полностью протестировать свои интеграции. Интеграции сторонних разработчиков моделируются с другими адаптерами.

Как это работает на практике?

Каждая из их бессерверных функций имеет lambda.js и main.js файлы. Основной файл содержит бизнес-логику бессерверной функции. И lambda.js файл отвечает за подключение адаптеров и вызов main.js файл.

Основной файл имеет свой модуль и интеграционные тесты. Но его интеграционные тесты не проверяют полную интеграцию с конечными сервисами, такими как AWS S3, поскольку это замедлило бы их. Вместо этого они используют адаптер памяти для проверки функции с интеграцией хранилища файлов.

Интеграция AWS S3 осуществляется с помощью FileRepository, который имеет свой собственный блок и интеграционные тесты. Проверки интеграционных тестов используют AWS S3, чтобы убедиться, что конечная интеграция действительно работает.

В отличии от main.js, lambda.js файл не имеет тестов, так как в большинстве случаев он содержит всего несколько строк кода.

eokIvJ-PIBMhzLPIoNFu7qThfVsmwQjiGtWS
Визуальное представление одной функции AWS Lambda с тестами

Этот подход похож на технику, используемую командой MindMup для тестирования бессерверных функций. С его помощью можно легко тестировать интеграцию своих функций и при этом делать интеграционные тесты быстрее.

Тестирование графического интерфейса

Поскольку Алекс и его команда создавали бэк-энд для программы, уровень тестов GUI не был актуален. Но когда они узнали больше о бессерверном режиме, они поняли, что могут использовать его для улучшения уровня тестов GUI для других приложений, над которыми они работали.

Тесты пользовательского интерфейса дорогие и медленные, поскольку выполняются в браузере. Но бессерверный дешев и быстро масштабируется.

Если бы они могли запустить браузер в AWS Lambda, они получили бы дешевую параллелизацию. Это сделало бы их тесты UI более дешевыми и быстрыми.

Но вы можете запустить браузер, например Chrome, в бессерверной функции?

Да! И это легко с помощью таких инструментов как бессерверный Chrome, Chromeless и Puppeteer.

5eoKemm0zOuNq3KphM3a6exI-WwjZxffmFe6
Использование функций AWS Lambda для распараллелирования тестов пользовательского интерфейса

Сочетание браузеров без серверов и безглавных браузеров может принести нам новое поколение инструментов тестирования пользовательского интерфейса. Мы можем увидеть и попробовать некоторые из них, например Оценить.

CI/CD

Поскольку Алекс и его команда тестировали свою первую функцию без сервера, пора развернуть код в среде тестирования. Это вызвало новый вопрос: как они могут использовать инструменты CI/CD для развертывания своего бессерверного приложения?

t2czuwldXzmq1WQJyz9z4bcH-zcEHjvtRPAX

Ответ прост: они могут использовать инструмент CI для запуска тестов и развертывания программы. Чтобы развернуть приложение, воспользуйтесь любым популярным инструментом, таким как Claudia.js, AWS SAM и Serverless Framework.

Вы все еще можете использовать свой любимый инструмент CI (например, Jenkins, TravisCI или SemaphoreCI), или если вы хотите придерживаться AWS, вы можете попробовать AWS CodeBuild.

Ручное тестирование

Даже с помощью ручного тестирования, на которое непосредственно не влияет бессерверное, команда нашла способ улучшить свой процесс QA.

iKbkUkU7K9X0TFyMDarE3df68GjSG-3peTgK

Этапы и развертывание бессерверного приложения дешевы и часто быстро настраиваются. Кроме того, без сервера вы не платите за приложение, если его никто не использует.

Это значит, что тестовая среда еще никогда не была дешевле!

Кроме того, с бессерверным, вы можете часто продвигать функция от одной стадии к другой. Это означает, что ваша команда QA может протестировать функцию, и когда они подтвердят, что она работает, вы можете продвигать ту же функцию к производству.

За пределами тестирования

Алекс и его команда передали свою первую бессерверную функцию для предварительного производства, и команда была счастлива, что научилась тестировать бессерверные программы.

5ctT2IR50soRZdzNTojzOv-07ddy6ThSKsS2

Они продолжали использовать в проекте бессерверный режим и представили его в ряде других проектов. Алекс присоединился к своим друзьям Анне и Джеффу как третий, иногда раздражительный, бессерверный проповедник. И жили они долго и счастливо.

fkvnvW6w0JSsdN1R6HrDbzkBgviZ12wNHI3e
Команда бессерверных проповедников получила нового члена

Послесценарий

Но, несмотря на то, что их программа была хорошо проверена, что-то произошло за ночь.

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

Поскольку бессерверные программы сильно зависят от интеграции, риск переходит с вашего кода на интеграцию. А чтобы иметь возможность уловить изменения интеграции и быстро реагировать, ваше приложение требует надлежащего мониторинга.

К счастью, с каждым днем ​​на рынке появляется все больше бессерверных инструментов мониторинга. Некоторые из хороших и популярных вариантов – IOpipe, Thundra, Dashbird и Epsagon.

Но у бессерверных программ часто есть толстый клиент, а это значит, что мониторинга серверной части недостаточно. Вам нужен схожий инструмент для передней части. На этом рынке также много хороших инструментов, таких как Sentry и Rollbar.

Но в духе бессерверности мы создали приложение с открытым исходным кодом для отслеживания ошибок под названием Desole. Это приложение без сервера, которое можно установить в своем аккаунте AWS. Это позволяет организациям отслеживать исключения и ошибки приложений, не выбирая между удобством ПО как услуги и безопасностью самостоятельного решения. Вы можете проверить это здесь: https://desole.io.

g874CpDwSRlIUinEuRFszzJVYRxy9G75Ewrp
Desole, открытый исходный код для отслеживания ошибок, тесно интегрирован с AWS

Все иллюстрации созданы с помощью программы SimpleDiagrams4.

Если вы хотите узнать больше о тестировании и создании бессерверных программ с помощью Node.js и AWS, посмотрите книгу «Бессерверные программы с Node.js», которую я написал вместе с Александром Симовичем для Manning Publications:

Бессерверные программы с Node.js
Убедительное вступление в бессерверное развертывание с помощью Claudia.js.www.manning.com

В книге вы узнаете больше о бессерверном тестировании с примерами кода, но вы также узнаете, как создать и наладить реальный бессерверный API (с базой данных и аутентификацией) с помощью Node и Claudia.js. И вы узнаете, как создавать чат-боты для Facebook Messenger и SMS (с помощью Twilio), а также навыки Alexa.

Добавить комментарий

Ваш адрес email не будет опубликован.