В каждом проекте стратегия автоматизации тестирования основана на пирамиде тестирования (может быть, больше 😮), но хорошо ли она понятна?

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

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

Мы попытаемся определить пирамиду, а затем попытаемся проанализировать, как она была построена.

Определение

Самый распространенный

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

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

Что такое единица?

Каждый задает вопрос: «Что такое единица?»: Функция, класс, функция,…? Здесь есть консенсус: термин расплывчатый.

Когда у вас есть пирамида с нечетким основанием, это плохо.

Интегрировать, как?

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

E2E, без ограничений?

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

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

Чтобы найти пояснения, возможно, поможет вернуться к истокам пирамиды тестов.

Оригинал

Первая версия исходит от Майка Кона, который описал ее в своей книге Успех с помощью Agile.

Определение

Вот краткие определения из книги:

  • Модуль: самая большая часть, дает конкретную обратную связь программисту, обычно пишется на том же языке, TDD.
  • Сервис: поведение приложения без графического интерфейса, с использованием таких инструментов, как FitNesse, ATDD.
  • UI: как можно меньше, гораздо меньше, чем любой другой тип теста, хрупкий, дорогой, требующий много времени), убедитесь, что службы подключены и что значения отображаются правильно

Unit == xUnit

В то время наиболее используемым фреймворком был xUnit. Модульный тест относится ко всему, что может быть протестировано фреймворком xUnit.

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

Майк Кон связывает Модульное тестирование с практикой TDD. Это значит, что они пишутся на лету. Поскольку тест-кейс написан разработчиком, это скорее технические тесты.

Сервис, ориентированный на поведение

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

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

На этом уровне тесты более ориентированы на поведение, в идеале они проводятся с использованием практики ATDD (в своей книге Майк Кон упоминает инструмент Fitnesse).

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

Сервисные тесты включают обмен с внешними компонентами.

[Service Tests] -> [Backend] -> [DB, External Service]

UI, остальное

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

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

Согласно этому предложению, мы делаем вывод, что то, что тестируется через пользовательский интерфейс, - это интеграция между интерфейсом и сервером. Здесь нет упоминания о тестах пользовательского пути (также известных как горизонтальный E2E).

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

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

С точки зрения бизнеса будет указано несколько тестовых случаев:

Если мы протестируем весь тестовый пример через UI, он выполнит множество тестов. Отсюда идея выполнить их на один уровень ниже.

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

Заворачивать

Мы можем сделать в сводной таблице: