Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Всем привет! Я Максим Кузнецов, и я продолжаю цикл статей рассказом об инструменте автоматизированного тестирования в Росбанке.
В прошлый раз вы читали:
- Fast-Unit или декларативный подход к юнит-тестам
- Tladianta. Сервис по автоматизированному тестированию в Росбанке
Я сегодня расскажу о самом инструменте – фреймворке Tladianta.
Этот инструмент задумывался как база для легкого течения процесса тестирования в его новом виде. Менеджеры придумывают процесс и управляют им, а исполнителям нужен инструмент, а лучше — семейство инструментов, которое отражает и обслуживает процесс.
Tladianta – это первый базовый инструмент сервиса по автоматизированному тестированию, который наша команда предоставляет на весь банк.
Какие задачи он должен решать?
Предполагается использование фреймворка во многих командах. Много-много задач типа «get started». В идеале должно быть так: создал проект и начал сразу писать тестовые сценарии.
Каждая команда будет использовать определенную часть фреймворка (или несколько) и эта часть должна легко обновляться и быть всегда стабильной.
Легкость поддержки сотрудниками сервиса АТ должна быть на уровне «я не сильно разбираюсь в специфике проекта вашей команды, но в том, как работает фреймворк тестирования Tladianta, я вам помогу на 100%».
В банке много разного продуктового ПО как для клиентов, так и для самого банка и, следовательно, много команд это ПО разрабатывающих либо поддерживающих. Классически это ПО разработано на таких платформах как:
- Web (HTML, CSS, JavaScript),
- Desktop (Delphi, C++ и прочие),
- Mobile (Android, iOS),
- Back-end(REST-services, MQ’s очереди).
Фреймворк должен позволять писать тестовые сценарии для любой из них, оставаясь при этом в процессе Tladianta
Фреймворк должен позволять команде разработки этого фреймворка расширять функционал тестирования как для основных платформ, так и добавлять новые автономные модули для тестирования специфических областей разработки ПО.
При этом изменение и доработка функционала фреймворка не должны приводить к поломке уже написанных на нем тестов в командах.
Вот мы пришли в команду с «чемоданом счастья», прошли «Get started» и начали писать тесты сразу, используя функционал «из коробки».
Это в идеале.
На деле же команде требуется добавить свою специфику. Например, переписать работу шага, изменить механизм поиска элемента страницы, механизм конфигурирования, добавить свои каркасы или утилиты и т.д.
Все это должно работать и при этом оставлять проект с использованием нашего фреймворка «на поддержке» командой сервиса АТ.
Что в BDD клёво, так это человеко-читаемый и одновременно авто-исполняемый текст сценария. Важно, чтобы все члены команды могли прочитать сценарий и понять, какую часть функционала протестировали.
BDD каким он задумывался: аналитик пишет сценарий, разработчик его воплощает, а автоматизатор делает его авто-исполняемым.
В банке же реальность – это различные гибридные варианты. Например:
- ПО куплено «из коробки» или разработано вендором, а команде нужно контролировать основные сквозные сценарии;
- команда разработки ПО в банке и команда тестирования – это две разные команды. Ситуация немного похожа на первую, только разработка внутри банка. Так, команда тестирования создает свои e2e тесты, чтобы контролировать основные сценарии и свои доработки;
- Legacy ПО, которое взяли на поддержку и стали покрывать тестами.
То есть это уже Behavior Driven Testing – когда разработка уже давно завершена. А вот прелесть человеко-читаемого описания поведения сложно переоценить и этот подход нужно учесть наравне с классическим BDD.
Значит, фреймворк должен говорить на языке Gherkin.
У нас много команд, разные платформы, Gherkin и необходимость дать и поддерживать единый инструмент. Вывод – нам нужна единая библиотека шагов на все случаи жизни платформы и возможные действия.
Чтобы описать атомарные действия пользователя в любой тестируемой системе, нужно не так много шагов, как может показаться с первого взгляда. Сложности скорее в том, как шаг будет реализован для конкретной системы или платформы, а не в том, как эти шаги должны быть сформулированы.
То есть нам нужно иметь 80% всех необходимых шагов, чтобы можно было «сразу начать писать» сценарии, а оставшиеся 20% шагов добавлять под специфику проекта.
В банке большое число сложных IT-систем, которые переплетены между собой довольно сильно, и в случае e2e сценариев иногда бывает очень сложно обойтись без того, чтобы не проделать ряд действий (подготовительных или проверочных) в другой системе, – не в той, которую тестируем сейчас.
Вот эту другую систему поддерживает другая команда, которая пишет для нее свои тесты. На нашем фреймворке. То есть все простые действия, которые нужно сделать в их системе, эта команда уже автоматизировала.
Вывод прост – чтобы не автоматизировать все опять на свой лад типа «я художник, я так вижу», нужно иметь возможность просто использовать шаги из проекта той системы, в том виде и с той реализацией.
Многослойная архитектура фреймворка предполагает такие же послойные наборы свойств конфигурации.
Нужен механизм сборки итоговой конфигурации, который заставит фреймворк работать так, как этого требует специфика проекта тестирования на уровне команды. Например, будет учитывать среды запуска, подключение к различным внешним инструментам и сервисам и т.д.
Нужно охватить еще такой случай. Допустим, команда поддерживает и тестирует некий портал и в сценариях зачем-то нужно «сходить» в back-end, например, через REST проверить результат или через него же подготовить данные (вдруг с разработкой все по науке сделано :-) ).
Другими словами, тестируем Web и нужно не отходя от кассы что-то сделать в REST. За обе эти части отвечают разные модули, и нужно иметь возможность использовать их одновременно в сценарии.
Это требование про сервис отчетности. Должно быть удобно:
- взглянуть на отчет о прогоне конкретного сценария и сразу понять, где и что сломалось, какая часть функционала отвалилась. Быть в состоянии это понять должен любой член команды — в смысле ясности изложения самого сценария и отображения тестовой модели;
- провалиться глубже в лог, посмотреть картинки, видео и другие вложения и понять, почему сценарий упал, чтобы потом исправить то, что поломалось;
- перезапустить сценарий и/или зависимый регресс после расследования и исправления, прямо не отходя от
кассыотчета.
Об этом было понемногу в пунктах выше, но некоторые моменты стоит выделить отдельно. BDD ориентированность фреймворка подразумевает сценарные тесты, а они бывают в основном функциональные и end-to-end.
Сквозные тесты в банке это не «залогинился – удивился –разлогинился». Это, например, проверка работы оператора, который сидит и переключается между несколькими приложениями, выполняя одну операцию с клиентом. Сквозные сценарии почти всегда затрагивают и другие системы.
Да, следует максимально делать независимые тесты, но в случае, если иначе никак, создание и прогон таких сценариев должны быть максимально безболезненными. Заглушки — это благо, но не всегда они есть и часто создать их невозможно.
Фреймворк должен задавать общие правила и давать равные возможности для автотестирования многим (в идеале всем) командам. В этом случае он просто обязан быть удобным.
А значит, следующий шаг развития – переход к opensource внутри банка.
В процессе трансформации в банке образовалось много Agile-команд, которые, тем не менее, все еще работают на один результат – все ПО банка должно работать слаженно, в идеале без ошибок и приносить удовлетворение клиентам.
Чтобы избежать ситуации «кто в лес, кто по дрова» и делать выводы о здоровье ИТ-экосистемы в целом, необходим способ агрегации данных о качестве ПО и о том, насколько автоматизированное тестирование в этом помогает.
Первый шаг к этому – сделать общие правила сбора статистики прогонов и расчета на их основе метрик. Фреймворк должен давать возможность внедрения методик, которые помогут с формированием Dashboard’s и покажут результаты автоматизированного тестирования наглядно и для всех.
BDD задумывался его авторами для облегчения взаимодействия в команде трех ролей:
- аналитик/owner – знает, что должно получиться;
- разработчик – знает, как сделать то, что хочет owner;
- тестировщик – знает, как проверить то, что сделает разработчик, чтобы оно работало как хочет owner.
В команде они в тесном общении создают качественный продукт.
Фреймворк должен быть удобен как инструмент в этом взаимодействии: он должен говорить на языке owner’а, быть понятным разработчику и удобным для тестировщика.
Далее поговорим об основных (но не всех) функциональных возможностях фреймворка (фичах) и о том, как каждая из них решает поставленные выше задачи.
Архитектура
Tladianta реализована на архитектуре компонентов типа "Звезда", где центральной частью является компонент "common", который предоставляет основные глобальные возможности фреймворка.
Плагины предоставляют функционал и реализацию шагов для конкретного стека технологий (платформы), на которых написано тестируемое приложение.
Плагинов в семействе компонентов фреймворка пока 4:
- HTML-plugin — для тестирования веб-приложений, сайтов, порталов и пр. на различных браузерах;
- Desktop-plugin — для тестирования desktop-приложений, написанных на Swing, AWT, .Net и пр. языках высокого уровня, Windows-приложения, а также терминальные. Например, Bank Information System;
- Mobile-plugin — для тестирования мобильных приложений на iOS/Android;
- Rest-plugin — для тестирования REST API приложений любых типов.
Ассортимент и функционал плагинов может (и будет) расширяться. Плагин должен отвечать небольшим требованиям, чтобы иметь возможность работать под управлением "common".
Так, у каждого модуля есть своя команда разработки, которые работают почти независимо.
Какие задачи решает:
- охват основных платформ разработки;
- простота наращивания функционала фреймворка;
- одновременное использование нескольких платформенных модулей;
Конфигурирование
Запуск тестов на выполнение, как правило, конфигурируется различными свойствами. Эти свойства имеют различные области (уровни) влияния.
Так, например, можно выделить:
Кроме того, часто нужно задать значения свойств любого уровня специально для среды запуска: DEV, TEST, CERT, а также опционально добавлять к набору свойств конфигурации группу свойств под конкретный тест или группу тестов (настройки подключения к базе данных, стороннему сервису и прочие).
В Tladianta реализован механизм сборки свойств конфигурации, а также предусмотрена возможность установки собственного механизма сборки свойств, более подходящего для проекта. Единственное требование – свойства уровня фреймворка и плагина должны присутствовать и они должны быть инициализированы.
По умолчанию конфигурация собирается следующим образом:
Загрузка свойств происходит по принципу "каждый следующий затирает предыдущего". Перезапись значения свойства происходит по имени свойства.
Такой подход дает возможность переопределять свойства уровня фреймворка и/или, плагина в проекте, в свойствах среды и т.д.
Какие задачи решает:
- легкий старт и удобство настройки;
- Возможность настройки «под команду» или «под систему»;
- гибкий механизм конфигурирования проекта с тестами;
Контекст исполнения сценария
Контекст здесь означает закешированные Java-сущности, которые устанавливаются при старте каждого сценария и обеспечивают корректное исполнение его шагов.
Контекст состоит из
В Tladianta реализован механизм регистрации действий для установки контекста проекта. Это такой список отложенных действий, который есть у плагина и у проекта.
Таким образом, в зависимости от используемого плагина и собственных наработок,
команда проекта тестирования может формировать свой набор действий по инициализации контекста запуска каждого сценария.
Такой подход позволил заложить удобство при переходе на контекст другого проекта и использование его шагов прямо в том же самом сценарии (см. далее).
Какие задачи решает:
- возможность делиться шагами с другими командами;
- удобство e2e тестирования.
«Гостевой» модуль — использование шагов и контекста других проектов.
Допустим, две независимые команды разрабатывают авто-тесты для двух различных приложений, создают свои уникальные шаги и java-сущности (страницы, элементы и пр.), а также переопределяют методы шагов из библиотеки фреймворка.
В своих проектах команды реализуют тестовое взаимодействие со своим тестируемым приложением — клики, заполнение полей, проверки и т.д.
Повторю еще раз — в банке все приложения связаны между собой и образуют IT-экосистему, и появляются сквозные сценарии, в которых нужно часть действий сделать в другом приложении. Не обложить заглушками (хотя это и правильно), а именно вживую проделать.
Я прекрасно понимаю гнев и негодование BDD-евангелистов, но что есть, то есть.
В таких уникальных случаях можно подключить проект другой команды в свой проект как зависимость и использовать их шаги и сущности без необходимости их дублирования в своем проекте.
Для реализации такой возможности Tladianta имеет спец шаги переключения контекста.
Вот тут и пригодились те самые отложенные действия.
Сценарий при этом может выглядеть так:
Каждый проект на базе Tladianta должен иметь свойство конфигурации app.name с понятным человеку именем. Это имя идентифицирует контекст проекта и используется для переключений/установки контекста в сценарии.
В момент переключения контекста сценария будут выполнены все [отложенные] действия установки контекста, зарегистрированные для конкретного проекта.
Чтобы любой проект на базе Tladianta можно было использовать как гостевой в других проектах, он должен отвечать ряду требований:
- проект тестирования должен быть построен на базе Tladianta-framework;
- проект тестирования должен собираться по релизам и публиковаться в банковский репозиторий nexus;
- проект подключается как гостевой через зависимость в POM-файле принимающего проекта. Последний стабильный релиз;
- проект тестирования в процессе сборки релиза должен включать ресурсы с файлами свойств конфигурации.
Таким образом, все проекты тестирования объединяются в единую экосистему тестирования, подчиненную общим правилам, что значительно упрощает их поддержку силами отдела сервиса АТ, одновременно сохраняя индивидуальность каждой команды.
Какие проблемы решает:
- легкая поддержка и возможность обновления для всех команд – в части легкой поддержки;
- единая библиотека шагов сценария – шаги одни и те же, а реализация в командах может быть разной;
- возможность делиться шагами с другими командами;
- удобство e2e тестирования.
Библиотека шагов.
Tladianta реализует принцип "Создай шаг один раз и переопределяй его метод, где нужно".
Шаги, составляющие библиотеку, разбиты на несколько уровней:
- общие шаги для всех проектов на базе любых плагинов;
- шаги плагина;
- шаги проекта.
Вместо классической реализации шагов cucumber Tladianta разделяет определение шага (step definition) и реализацию шага (step implementation) на две разные сущности.
Это позволило отделить формулировки шага и собрать их в библиотеку, оставив плагинам и проектам работу над реализацией конкретного поведения шага.
Таким образом, одна формулировка шага может иметь разную реализацию в разных плагинах и проектах.
Создавая сценарий, больше не нужно беспокоиться о том, что шаг "занят" в другом плагине и нужно дублировать его у себя, меняя формулировку или вставляя разные костыли в виде символов точек, лишних пробелов и так далее, чтобы избежать ошибки "Multiple step definition found".
Вместо этого нужно просто переопределить метод этого шага в своем проекте или даже на конкретной странице.
Внешнее поведение шага, интуитивно ожидаемое от его формулировки, останется тем же, скрывая под капотом нюансы его реализации в каждом конкретном случае.
Мы постарались собрать в библиотеку те самые 80% шагов, которые позволят сразу «из коробки» написать сценарий средней сложности.
Роль сервиса АТ также позволяет нам вылавливать из оставшихся 20% шагов, которые команды делают себе сами, те шаги, которые объективно нужны многим, и мы добавляем их в библиотеку фреймворка. Автоматизаторы в командах, таким образом, принимают участие в развитии инструмента.
Какие задачи решает:
- возможность настройки «под команду» или «под систему» — в части реализации шагов;
- BDD стиль в написании сценариев;
- единая библиотека шагов сценария;
- увеличение вовлеченности автоматизаторов «на местах» в развитие инструмента.
Тестовые данные и шаблоны генерации значений параметров шагов
Cucumber дает возможность часть текста шага использовать как параметр. Это очень удобно.
Tladianta расширяет эту возможность динамической параметризацией шагов.
Например, в шаге вам нужно использовать номер договора, дату, номер счета и прочее. Чтобы не писать все эти значения сразу в шаге, затрудняя при этом поддержку теста, можно в места параметров шага вставить шаблон автозамены, а сами значения собрать в некие файлы и поддерживать уже их.
Tladianta перед выполнением сценария все шаблоны заменит на конкретные значения из тестовых данных и в отчетах о прогоне вы увидите уже их.
В качестве источников тестовых данных могут использоваться:
- Json
- Excel
- Properties
- Mongo DB
Генераторы значений
Не все тестовые данные можно спрогнозировать заранее и завести их в файлы. Некоторые значения имеют смысл прямо в моменте исполнения теста, например, текущая дата, случайное число и т.д.
Tladianta представляет очень удобный механизм генерации текстовых значений "на лету" — это генераторы значений.
Работают они так же, как и шаблоны авто-замены тестовых данных, но имеют немного другой синтаксис и время срабатывания.
Генераторы значений отрабатывают уже после подстановки тестовых данных.
Механизм генераторов значений гибок и расширяем, т.е. в проекте тестирования можно изменить работу генераторов "из коробки", а также добавить свои собственные генераторы и использовать их в своих сценариях.
Какие проблемы решает:
- возможность настройки «под команду» или «под систему»;
- BDD стиль в написании сценариев.
Древовидная структура
Продолжаем тему длинных сквозных сценариев.
Тут есть дилемма – атомарные шаги или читаемый сценарий.
Правильно – это и то, и другое.
Атомарные шаги легко переиспользовать, но при этом страдает читаемость и «за деревьями леса не видно». А если объединять группу действий в один шаг, тогда такой «толстый» шаг невозможно использовать в другом месте.
Обычно такие сценарии подлежат рефакторингу — разбивке на части и упрощению. Беда в том, что после разбивки, такие части сами по себе теряют смысл.
Например, у нас есть сценарии из 700+ шагов. Это большие такие сквозные сценарии. В функциональных тестах отдельные части протестированы. А в этом e2e сценарии ничего не выкинуть. Только читать и поддерживать его невозможно. Что делать?
Мы сделали сценарий древовидным.
Он остается плоским с точки зрения cucumber, а вот с точки зрения человека он выглядит, как дерево. Атомарные шаги сгруппированы, а группы названы объединяющей фразой. Это такие комплексные «толстые» шаги, которые не шаги, их не нужно переиспользовать, т.к. они как шаги не существуют.
Например,
Комплексные действия тоже объединяются в группы, уже логические, такие бизнес-шаги.
Например,
Вы заметили, что это уже не cucumber шаги?
Это то, что понимает, скажем, аналитик, который знает «назубок» этот сквозной сценарий. Если сценарий «упадет», он довольно быстро сможет понять, в каком месте сломалось. Ему не нужно быть для этого автоматизатором. Ему достаточно уметь открыть отчет Allure и знать русский язык.
Древовидное отображение сценария мы сделали в среде разработки и в отчете Allure.
Узлы дерева можно сворачивать и читать сценарий «по верхам».
Удобно и писателю сценария, и его читателю.
Удобно в разработке – можно делить сценарий на части и делать параллельно.
Удобно в отладке и расследовании падения – открыл Allure отчет и почти всегда, не выходя оттуда, понимаешь, в чем проблема.
Какие задачи решает:
- BDD стиль в написании сценариев;
- удобство в расследовании падений и сбора результатов;
- удобство e2e тестирования.
- использование в Agile-командах
Page Object
Мы выбрали шаблон PageObject для архитектуры автотеста как основной, но не единственный. Просто он объектно-ориентированный, это так по java’вски.
Команда в своем проекте может использовать другой паттерн. Она всего лишь должна выполнить требования по библиотеке шагов и переключении контекста и все, полная свобода.
Вкратце PageObject предполагает описание формы или экрана приложения как отдельного java-класса, а поля класса — это части интерфейса формы: поля ввода, кнопки, флажки, таблицы и прочее.
В сценарии специальным шагом
объект страницы устанавливается как текущий и дальнейшие шаги работают в контексте этой страницы.
Блоки.
Страницы бывают сложные: много вкладок, разных сгруппированных полей и часто у этих полей одинаковые относительные пути (xPath), что наводит на мысль о DRY, переиспользовании, ООП в конце концов.
Логично выделить их в отдельную сущность и вообще разбить страницу на группы, области.
Однако группа полей логически не является страницей.
Поэтому было введено понятие блоков — это такие специальные классы, не являющиеся страницей в парадигме PageObject, единственная цель которых – облегчение класса страницы и переиспользование группы полей на страницах проекта.
Когда группа полей визуально выделена на странице, удобно использовать навигацию вида «хлебные крошки» для обращения к элементу страницы из шага сценария.
Например, на странице есть два повторяющихся элемента: "Номер" и "Остаток". Они присутствуют на странице в двух местах: "Данные счета" и "Данные карты".
В этом случае элементы "Номер" и "Остаток" нужно вынести в отдельный класс-блок, а на страницу добавляем два элемента-блока "Данные счета" и "Данные карты".
В шаге обратиться к элементу "Остаток" для разных блоков можно следующим образом:
Блоки элементов могут быть вложены друг в друга
Блоки могут быть списками
Такая навигация очень помогает ориентироваться в сценарии и приложении.
Части пути к элементу должны быть названы так, как они выглядят на форме/странице. То есть, читая сценарий, можно сразу глазами находить элемент на экране и понимать, что куда заполняется и где нажимается.
Довольно удобно.
Какие задачи решает:
- BDD стиль в написании сценариев.
- удобство в расследовании падений и сбора результатов.
- использование в Agile командах – всем просто понять сценарий
Использование нескольких плагинов в одном проекте
В одном проекте допускается использование сразу нескольких плагинов из семейства Tladianta.
Это не то же самое, что и использование кода гостевого проекта, который может быть написан на базе плагина, отличного от плагина текущего проекта.
Здесь речь идет об использовании шагов разных плагинов в одном проекте и в одном сценарии.
В этом случае функционал переключения контекста не имеет смысла, т.к. контекст проекта общий для обоих плагинов. Это нужно учитывать при создании java-сущностей (страниц, блоков, шагов и т.д.).
Самая распространенная ситуация – это когда нужно результат действий через UI проверить через REST запросы к бэкенду приложения.
Какие задачи решает:
- одновременное использование нескольких платформенных модулей;
Запись видео.
Tladianta представляет конфигурируемый и настроенный "из коробки" инструмент записи видео по умолчанию, который, однако, можно переопределить или добавить свой у себя в проекте.
Перед запуском теста фреймворк запускает все зарегистрированные видео-рекордеры и по окончании сценария останавливает их.
Настройки поведения видео-рекордера (вкл/выкл, сохранять видео всегда или только при падении и пр.) можно использовать общие или добавить свои только для проекта.
Какие задачи решает:
- возможность настройки «под команду» или «под систему».
- гибкий механизм конфигурирования проекта с тестами.
- удобство в расследовании падений.
Allure-report
По-умолчанию результаты прогона тестов логируются в Allure-отчет. Логирование поддерживает древовидную структуру сценария, если она используется. В отчет попадают также логи, сделанные с помощью Sl4j.
Allure позволяет группировать сценарии по Epic/Feature/Story/Case. Это полезно, если у вас есть (должны быть) тестовая модель и матрица зависимости. И когда просматриваешь отчет, который сгруппирован так, как у вас модель тестовая составлена, то становится очень удобно, т.к. по упавшему тесту в отчете сразу видно, какой связанный функционал пострадал и потенциально стал нерабочим.
Требование к наличию модели и матрицы зависимости в сочетании с отчетами в Allure позволяют создавать базу для внедрения различных методик расчета метрик, т.к. все команды выгружают такие результаты.
Все результаты собираются в одном месте по проектам/командам и вместе дают ту самую целую картину здоровья ИТ-ландшафта. Причем, собираются также результаты тестов, которые написаны не на Tladianta.
Это уже не фреймворк Tladianta (он только генерирует данные), это уже процесс Tladianta.
Какие задачи решает:
- BDD стиль в написании сценариев.
- удобство в расследовании падений.
- единая отчетность, сбор метрик и легкое формирование Dashboard’s.
- Использование в Agile командах
Передача данных между шагами и сценариями.
Идеология cucumber настаивает на том, что каждый шаг сценария по своему поведению должен быть независимым и самодостаточным (атомарным). То же относится и к сценарию.
Однако бывают случаи, когда атомарность шага немного мешает и нужно иметь некий временный кэш сценария.
Таким кэшем во фреймворке выступает временный объект – контекст сценария. Он позволяет в одном шаге сохранить какое-либо значение в переменную, а в следующем шаге использовать его.
По умолчанию контекст сценария очищается перед каждым новым сценарием, однако это поведение можно отключить и использовать его для передачи значений между сценариями в течение одного запуска всех или группы тестов.
Кроме того, данный контекст можно закрепить за конкретным сценарием и сохранить его в базе данных. Опционально. Для этого есть отдельные методы, их можно использовать в Before/After-хуках в проекте.
По-умолчанию контекст сценария очищается перед каждым сценарием и не сохраняется в базу данных.
Таким образом, можно создавать предустановленные значения временных данных для каждого сценария.
Какие задачи решает:
- удобство e2e тестирования;
Шаблонные проекты.
Это часть семейства инструментов Tladianta.
Мы сделали заготовки, шаблоны проектов, которые настроены на работу с каким-то одним плагином. Сделали в них структуру со всеми ключевыми пакетами и классами. Сделали настройку для фичи «гостевой проект», для выгрузки отчета Allure.
Просто делай клон, пиши имя проекта и начинай писать тесты.
В проектах можно кастомизировать почти все, что может фреймворк:
- реализацию шагов
- механизм конфигурирования
- механизм поиска элемента страницы
- работу с рефлексией
- генераторы значений
- порядок инициализации контекста проекта
- можно использовать свои инструменты записи видео
- использовать не PageObject.
Какие задачи решает:
- легкий старт и удобство настройки;
- охват основных платформ разработки;
- возможность настройки «под команду» или «под систему»;
Интеграция с внешними сервисами и инструментами.
Фреймворк позволяет подключать к нему различные интеграторы/выгружаторы результатов выполнения теста.
Мы сделали репортер в ALM и репортер в Jira.
Jira-reporter, например, создает задачу на реализацию новых шагов на автоматизатора в команде, а также задачу на расследование падения сборки со всеми ссылками и логами.
Tladianta-editor
Это плагин для среды разработки IntelliJ IDEA.
Его основное назначение – повысить скорость и комфорт в разработке сценария.
Можно создать рабочий сценарий не выходя из файла «.feature», при условии что использован шаблонный проект, конечно.
Он позволяет:
- выбрать шаг из доступной библиотеки шагов
- перейти из шага сразу в его step definition (это должно быть знакомо)
- позволяет создать заглушку step definition для нового шага (это тоже)
- выбрать страницу из списка в шаге установки текущей страницы
- а также создать новую страницу с элементами и блоками, не уходя из редактирования сценария
- «провалиться» в класс страницы, если уж так сильно нужно.
- набивать стрелочный путь до элемента в блоке, который в блоке и т.д.
- выбирать шаги гостевого проекта после переключения на его контекст
- выбирать страницы гостевого проекта после переключения на его контекст
- редактировать сценарий как дерево, добавляя и удаляя группировки шагов. Уровень вложенности любой
- и прочее.
Editor позволяет писать сценарий быстро, используя все возможности фреймворка и сводя к минимуму «возню» с рутинным кодом.
Реализацию нового шага или специфичную реализацию существующего шага придется все-таки писать самостоятельно. Но для этого есть автоматизатор :-)
Заключение
Как видите, мы нарушили много канонических положений BDD. При этом мы сделали cucumber пригодным для использования в наших банковских реалиях. Получился такой cucumber по-росбанковски. Поэтому и «Tladianta».
Не все идеи мы придумали сами. Многие из них мы почерпнули из трудов таких замечательных ребят как Константин Мальцев, Виктор Сидоченко, Алексей Лустин, Артем Ерошенко и других авторов open-source проектов.
Работа над фреймворком Tladianta не завершена. Мы его полируем и дополняем. Некоторые фичи еще не реализованы, о них, как и о представленных в статье, более подробно я расскажу в следующих статьях.
