По мнению экспертов, это наиболее эффективные стратегии тестирования микросервисов.

po mneniyu ekspertov eto naibolee effektivnye strategii testirovaniya mikroservisov?v=1656595221

автор Джейк Люметта

sbKYk9o8a9Bes7H2j8bzO0-DtZvoyQ7ajq9a
Фото Риккардо Аннандале на Unsplash

Тестировать микросервисы сложно. Точнее, сквозное тестирование сложно, и это то, что мы обсудим более подробно в этой статье.

Но сначала краткая история.

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

Поговорим о суетливости.

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

  1. Убедитесь, что я был в правильной ветке кода (или master или feature_xyz)
  2. Извлеките последний код для этой ветви
  3. Убедитесь, что все зависимости обновлены
  4. Запустите любую новую миграцию базы данных
  5. Запустите службу

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

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

Распространенные методы тестирования микросервисов

Модульное тестирование

Микросервис может быть меньше по определению, но с помощью модульного тестирования вы можете работать еще более подробно. Модульный тест сосредоточивается на наименьшей части программного обеспечения, которое можно проверить, чтобы проверить, работает ли этот компонент правильно. Известный инженер-программист, автор и международный докладчик Мартин Фаулер разбивает модульное тестирование на две категории:

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

Хотя эти стратегии модульного тестирования разнятся, Фаулер утверждает, что они не конкурируют – их можно использовать в тандеме для решения различных проблем тестирования.

При обсуждении с Дэвидом Штраусом, техническим директором Pantheon, Дэвид сказал мне, что «возможность заключается в том, что микросервисы очень просто проводить модульное тестирование».

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

С помощью интеграционных тестов вы делаете то, что звучит так, как вы делаете: тестируете пути связи и взаимодействия между компонентами для выявления проблем. По словам Фаулера, интеграционный тест «отрабатывает пути связи через подсистему, чтобы проверить наличие каких-либо неправильных предположений, которые каждый модуль имеет относительно того, как взаимодействовать со своими аналогами».

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

Павел Ледвонь, руководитель платформы Pusher, сообщил мне, что его команда[s] к интеграционному тестированию. Юнитные тесты все еще полезны для некоторых абстракций, но для функций, ориентированных на пользователя, трудно высмеять или пропустить важные части системы».

Не все, с кем я общался, были почитателями этого процесса. К примеру, стоит обратить внимание на взгляд Москеры на тему интеграционного тестирования:

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

Сквозное тестирование

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

Фаулер написал следующее:

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

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

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

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

Проблемы тестирования микросервисов

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

Вот несколько ключевых проблем, связанных с тестированием микросервисов:

  • Доступность: Поскольку разные команды могут управлять своими собственными микросервисами, обеспечить доступность микросервиса (или, что еще хуже, попытаться найти время, когда все микросервисы будут доступны одновременно), затруднительно.
  • Фрагментированное и целостное тестирование: Микросервисы предназначены для работы отдельно и вместе с другими слабо связанными службами. Это означает, что разработчики должны тестировать каждый компонент изолированно, а также тестировать все вместе.
  • Пробелы в знаниях: В частности, с интеграционным тестированием (которое мы рассмотрим далее в этой статье), проводящий тестирование должен иметь глубокое понимание каждого сервиса, чтобы эффективно писать тестовые случаи.

По словам Алексея Ковырина, руководителя Swiftype SRE компании Elastic,

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

Стефан Зрение, главный архитектор Sumo Logic, также повторил мне, что тестирование микросервисов действительно «очень, очень сложно».

«Особенно, когда вы переходите к более непрерывному развертыванию. Мы инвестировали и продолжаем инвестировать достаточно значительные средства в интеграционное тестирование, модульное тестирование, и сделали бы гораздо больше, будь у нас люди для этого», – сказал мне Зрение.

Учитывая это, он признал, что на определенных этапах, когда Sumo Logic хочет комплексно проверить свои услуги, более или менее [the] целая компания [becomes] в известном смысле команда по обеспечению качества».

Решение: пять стратегий тестирования микросервисов для стартапов

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

1. Стратегия «Первая документация».

Крис Макфадден, вице-президент Engineering Sparkpost, очень хорошо подытожил стратегию «Первая документация» во время нашего обсуждения:

Мы придерживаемся первого подхода к документации, поэтому вся наша документация находится в уценке GitHub. Наши документы API открыты, поэтому они общедоступны. Тогда, что мы сделаем, это перед тем, как кто-то напишет какие-либо изменения API или новый API, или изменения в API, они сначала обновят документацию, проверят это изменение, чтобы убедиться, что оно соответствует нашим конвенциям и стандартам API, которые все документировано, и убедитесь, что здесь нет особых изменений. Убедитесь, что он отвечает нашим условиям именования и т.д.

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

2. Стратегия полного стека в коробке

Стратегия полного стека в коробке подразумевает локальную репликацию облачной среды и тестирование всего в одном бродячем экземпляре ($ vagrant up). Проблема? Это очень сложно, как объяснила инженер-программист Синди Шридхаран из Imgix в своем блоге:

У меня был первый опыт с этой ошибкой в ​​предыдущей компании, в которой я работал, где мы пытались раскрутить весь наш стек в [local] бродячий ящик. Идея, как вы могли себе представить, заключалась в том, что бродяга должна позволить любому инженеру в компании (даже разработчикам интерфейса и мобильных устройств) иметь возможность раскрутить весь стек на своих ноутбуках.

Далее Шридхаран рассказывает о том, как у компании было всего два микросервиса, API-сервер на основе gevent и несколько асинхронных фоновых рабочих Python. Сравнительно простая настройка, в любом случае.

«Я помню, как провел всю свою первую неделю в этой компании, пытаясь успешно развернуть виртуальную машину локально, но натолкнулся на множество ошибок. Наконец, около 16:00 в пятницу моей первой недели мне удалось запустить настройки Vagrant, и все тесты прошли локально. Я помню, что чувствовала себя невероятно истощенной», – рассказала она.

Кроме того, Стефан Зиер, главный архитектор Sumo Logic, объяснил мне, что эта стратегия локализованного тестирования, кроме того, что ее трудно выполнить, просто не масштабируется.

“[With] локальное развертывание, мы запускаем большинство служб там, так что вы получаете полностью запущенную систему, и это сейчас довольно трудно растягивает даже машины с 16 ГБ RAM. Так что это не слишком масштабно», – сказал он.

3. Стратегия тестирования AWS

Эта третья стратегия подразумевает создание инфраструктуры Amazon Web Services (AWS) для каждого инженера для развертывания и проведения тестов. Это более масштабируемый подход к стратегии полного стека в коробке, о которой говорилось выше.

Зрение назвал это «личным развертыванием». [strategy]где каждый здесь имеет свой аккаунт AWS».

«Вы можете ввести код, который есть на вашем ноутбуке, в AWS примерно за десять минут и просто запустить его как настоящую систему», — сказал он.

4. Стратегия общих тестовых экземпляров

Мне нравится думать об этой четвертой стратегии как гибриде между полным стеком «в коробке» и тестированием AWS. Это потому, что разработчики работают с собственной локальной станции, одновременно используя отдельный совместный экземпляр микросервиса, чтобы указывать свою локальную среду во время тестирования.

Стивен Червински, руководитель инженерного отдела Scaylr, объяснил, как это может работать на практике:

Некоторые из [our] разработчики запускают отдельный экземпляр микросервиса только для использования для тестирования локальных сборников. Итак, представьте, что вы разработчик, вы разрабатываете на локальной рабочей станции, и у вас нет простого способа запуска анализатора изображений. Однако ваш локальный конструктор просто укажет на тестовый анализатор изображений, работающий в инфраструктуре Google.

5. Стратегия заглушенных услуг

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

Зиер изложил подход SumoLogic к тестированию заглушенных сервисов, сказав мне, как «заглушить, давайте вы напишете эти отметки или «заглушки» микросервисов, которые ведут себя так, словно это правильный сервис, и они рекламируют себя в нашем открытии сервисов так, будто это настоящая служба, но это только фиктивная имитация», – объяснил он.

К примеру, для тестирования службы может потребоваться, чтобы служба узнала, что пользователь выполняет набор заданий. С помощью заглушенных служб вы можете сделать вид, что пользователь (и его задачи) выполнялись без обычных сложностей, связанных с этим. Этот подход гораздо легче по сравнению с запущенными сервисами в целом.

Инструменты, которые помогут вам проверить микросервисы

Вот список инструментов, которые принесли мне пользу во время моего опыта тестирования микросервисов, подкрепленного некоторыми рекомендациями от команды технических директоров и старших разработчиков:

  • Hoverfly: моделирование задержек и сбоев API
  • Vagrant: создавайте и поддерживайте портативные виртуальные среды разработки программного обеспечения
  • Видеомагнитофон: инструмент модульного тестирования
  • Пакт: тестирование контрактов исходя из потребителей.
  • Пасека: инструмент документации API
  • API Blueprint: дизайн и прототип API
  • Swagger: дизайн и прототип API

Тестирование микросервисов: сложно, но оно того стоит

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

Кроме того, стратегии тестирования микросервисов, принятые такими как SumoLogic и Scaylr, должны помочь сгладить процесс. Вот краткий итог этих стратегий:

  1. Стратегия «Первая документация».
  2. Стратегия полного стека в коробке
  3. Стратегия тестирования AWS
  4. Стратегия общих тестовых экземпляров
  5. Стратегия заглушенного обслуживания

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

Если вам понравилась эта статья, пожалуйста, помогите ее распространению, хлопая ниже! Чтобы получить больше такого содержимого, следите за нами в Twitter и подпишитесь на наш блог.

Джейк Люметта – генеральный директор ButterCMS и публикует микросервисы для стартапов.

И если вы хотите добавить блог или CMS на свой веб-сайт, не возиться с WordPress, вам следует попробовать Butter CMS.

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

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