В каждом проекте стратегия автоматизации тестирования основана на пирамиде тестирования (может быть, больше 😮), но хорошо ли она понятна?
Хотя метафора тестовой пирамиды используется часто, у каждого свои интерпретации, поэтому можно найти разные пирамиды.
Когда вы отвечаете за проект и хотите иметь хорошую стратегию тестирования, необходимо понимать концепции и принципы техники, чтобы должным образом поддерживать то, что важно.
Мы попытаемся определить пирамиду, а затем попытаемся проанализировать, как она была построена.
Определение
Самый распространенный
Я думал, что найду официальное определение в Википедии, но чаще всего оно приходит из сообщений в блогах или на коммерческих сайтах. Вот избранные выдержки:
- Модуль: максимально быстро в изолированных условиях, тестирует отдельные компоненты или функции для проверки правильного пути, обработки ошибок и т. д.
- Интеграция: тестирует ваше приложение со всеми частями, которые находятся за пределами вашего приложения.
- 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 для отображения сообщения об ошибке рядом с полем.
С точки зрения бизнеса будет указано несколько тестовых случаев:
- [email protected] = ›хорошо
- abc = ›ко
- mel.com = ›ко
- [email protected] = ›ко
- [email protected] = ›ко
- …
Если мы протестируем весь тестовый пример через UI, он выполнит множество тестов. Отсюда идея выполнить их на один уровень ниже.
На уровне UI осталось протестировать только два случая: отправить по электронной почте нормально или по электронной почте ko. Вы можете заметить, что выходные данные службы становятся входными данными пользовательского интерфейса.
Заворачивать
Мы можем сделать в сводной таблице: