Паттерны и анти-паттерны CI/CD. Часть 2 +11


Всех с пятницей, друзья. Сегодня делимся с вами переводом второй части статьи «Паттерны и анти-паттерны CI/CD», первую часть которой можно прочитать здесь. Напомним, даная серия публикаций приурочена к запуску нового потока по курсу «DevOps практики и инструменты».

1.3 Паттерны и антипаттерны в тестировании

1.3.1 Автоматизация Тестирования

  • Паттерн: Автоматизируйте проверку и валидацию программного обеспечения, включив тестирование юнитов, компонентов, емкости, функционала и развертывания.
  • Анти-паттерны: Ручное тестирование юнитов, компонентов, развертывания и тд.
  • Юнит- Автоматизация тестов без зависимостей.
  • Компонент- Автоматизация тестов с зависимостями от других компонентов, баз данных и файловых систем.
  • Развертывание- Автоматизация тестов для проверки успешности развертывания и настройки. Иногда это называют “smoke”-тестированием.
  • Функционал- Автоматизация тестов для проверки поведения ПО с точки зрения пользователя.
  • Емкость- Автоматизация тестирования нагрузки и производительности в условиях, близких к эксплуатационным.



1.3.2 Изоляция Тестовых Данных

  • Паттерн: Используйте транзакции для тестов, зависящих от баз данных (например, тестирование компонентов) и откатите транзакции по завершении. Используйте небольшое подмножество данных для эффективного тестирования поведения.
  • Анти-паттерны: Использование копии данных с продакшн для Commit Stage тестов. Запуск тестов на общей базе данных.

1.3.3 Параллельные Тесты

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

1.3.4 Стаб Системы

  • Паттерн: Используйте стабы для симуляции внешних систем ради снижения сложности развертывания.
  • Анти-паттерны: Ручная установка и настройка взаимозависимых систем для Commit Stage сборки и развертывания.

1.3.5 Сквозное Тестирование Считается Вредным

Непрерывная Доставка — это набор холистических принципов и практик, направленных на снижение времени выхода на рынок. Он основывается на быстрой и надежной обратной связи благодаря тестам. Непрерывная Доставка требует от любых изменений кода, конфигурации, данных или инфраструктуры прохождения набора автоматизированных и exploratory тестов в Пайплайне Развертывания для оценки готовности к эксплуатации. Поэтому, если организация хочет добиться более коротких сроков, время выполнения тестов должно быть низким, а результаты тестирования — однозначными.

К примеру, рассмотрим сервис Платежи Компании, в котором платежи в конце года отправляются последующему сервису Платежей.

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

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

В то время как модульные и приемочные тесты различаются по назначению и объему, приемочные и сквозные тесты различаются только по объему. Приемочные тесты не включают бесхозные зависимые сервисы, поэтому приемочный тест путешествия пользователя Платежей Компании будет использовать Испытуемую Систему, состоящую из кода последней версии Платежей Компании и Стаба Платежей.

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

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

Конец второй части.

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




К сожалению, не доступен сервер mySQL