Экстремальное программирование, знакомство с Behavior Driven Development и RSpec
Теория
Для начала, давайте разберемся, что же такое Behavior Driven Development(в дальнейшем BDD) и чем данная техника отличается от Test-Driven Development(в дальнейшем TDD)
Разрабо́тка че́рез тести́рование (англ. test-driven development) — техника программирования, при которой модульные тесты для программы или её фрагмента пишутся до самой программы (англ. test-first development) и, по существу, управляют её разработкой. Является одной из основных практик экстремального программирования.
Хотя подход с предварительным тестированием работает у многих, он подходит не для всех. На каждого разработчика приложений, с успехом применяющего TDD, найдется несколько разработчиков, активно отрицающих этот подход. Несмотря на многочисленность инфраструктур тестирования, таких как TestNG, Selenium и FEST, все равно находится много причин не выполнять тестирование кода.
Две обычные причины отказа от TDD – «у нас недостаточно времени для тестирования» и «код слишком сложный и трудно проверяемый». Другой преградой для программирования с предварительным написанием тестов является сама концепция «тест пишется до кода». Большинство рассматривает тестирование как осязаемое действие, скорее конкретное, нежели абстрактное. Опыт подсказывает, что невозможно проверить то, что еще не существует. Для некоторых разработчиков, остающихся в рамках этой концепции, идея предварительного тестирования — просто оксюморон.
Но что если вместо того, чтобы думать в терминах написания тестов и тестирования компонентов, начать думать о функциональности? Говоря про функциональность, я имею в виду как приложение должно вести себя, фактически его спецификацию.
На самом деле большинство из нас уже и так думает подобным образом. Смотрите:
Линда: Это структура данных, хранящая объекты в порядке «первым вошел, последним вышел» или «последним вошел, первым вышел». Обычно у этой структуры есть API с такими методами, как push() и pop(). Иногда присутствует метод peek().
Фрэнк: Что делает метод push()?
Линда: Метод push() принимает входной объект, например, foo и помещает его во внутренний контейнер, например, массив. Метод push() обычно ничего не возвращает.
Фрэнк: Что будет, если передать методу push() два объекта, например, сначала foo, а потом bar?
Линда: Второй объект bar должен оказаться наверху концептуального стека, содержащего по крайней мере два объекта, так что при вызове метода pop() объект bar должен быть извлечен первым, до первого объекта foo. Если метод pop() вызвать еще раз, должен быть возвращен объект foo и стек должен стать пустым (предполагается, что в нем ничего не было до того, как мы добавили эти два объекта).
Фрэнк: Так метод pop() удаляет самый последний элемент, добавленный в стек?
Линда: Да, метод pop() должен удалить верхний элемент, при этом предполагается, что в стеке есть элементы, чтобы их удалять. Метод peek() работает точно также, но при этом объект не удаляется. Метод peek() должен оставить верхний элемент в стеке.
Фрэнк: Что будет, если вызвать метод pop(), когда в стек еще ничего не было добавлено?
Линда: Метод pop() должен выдать исключение, показывающее, что в стек еще ничего не добавлялось.
Фрэнк: Что будет, если выполнить команду push() null?
Линда: Стек должен выдать исключение, так как null не является допустимым значением для метода push().
Можно ли выделить что-нибудь особенное в этом диалоге, кроме того, что Фрэнк не силен в структурах данных? Нигде не использовалось слово «тестирование». Однако слово «должен» проскальзывало регулярно и звучало довольно естественно.
В подходе BDD нет ничего нового или революционного. Это просто эволюционное ответвление подхода TDD, где слово «тест» заменено словом «должен». Если отложить в сторону слова, то многие найдут понятие «должен» более естественным для процесса разработки, чем понятие «тест». Мышление в терминах функциональности (того, что код должен делать), приводит к подходу, когда сначала пишутся классы для проверки спецификации, которые, в свою очередь, могут оказаться очень эффективным инструментом реализации.
Практика
RSpec — это BDD framework для Ruby
git clone git://github.com/dchelimsky/rspec.git
cd rspec
rake gem
rake install_gem
describe Account, » when first created» do
before do
@account = Account. new
end
after do
@account = nil
end
describe Thing do
before(:all) do
# This is run once and only once, before all of the examples
# and before any before(:each) blocks.
end
before(:each) do
# This is run before each example.
end
before do
# :each is the default, so this is the same as before(:each)
end
it «should do stuff» do
.
end
it «should do more stuff» do
.
end
after(:each) do
# this is before each example
end
after do
# :each is the default, so this is the same as after(:each)
end
after(:all) do
# this is run once and only once after all of the examples
# and after any after(:each) blocks
end
В заключение
Если статья получит положительные отзывы, то появиться цикл статей на данную тему.
Для затравки, ниже несколько ссылок для углубленного, самостоятельного изучения:
BDD — рабочий метод или TDD в модной обертке?
Два подхода к разработке через тестирование вызывают особенно много споров — из-за некоторого методологического сходства TDD (Test Driven Development) и BDD (Behaviour Driven Development) часто путают даже профессионалы. Старшие инженеры по автоматизации тестирования «Альфа-Лаборатории» Юлия Ковалева и Анна Чернышева рассказывают базовые вещи о сходстве и различиях двух популярных методик и то, какой подход у них используется в самой компании.
Юлия Ковалева, старший Java-разработчик автотестов в «Альфа-Лаборатории»
Посвятила тестированию более 4 лет, сейчас разрабатывает библиотеку шагов для масштабирования автоматизации тестирования с использованием Cucumber и Selenide.
Анна Чернышева, старший Java-разработчик автотестов в «Альфа-Лаборатории»
Работала в крупных e-commerce проектах, участвует в создании и поддержке нескольких BDD-фреймворков, а также занимается внедрением инженерных и DevOps-практик.
— В чем заключается основное различие методик TDD и BDD?
Анна Чернышева: Понимание методик TDD и BDD отличается в разных компаниях, мы расскажем о том, как все устроено в «Альфа-Лаборатории». Концепции обоих подходов похожи, сначала идут тесты и только потом начинается разработка, но предназначение у них совершенно разное. TDD — это больше о программировании и тестировании на уровне технической реализации продукта, когда тесты создают сами разработчики. BDD предполагает описание тестировщиком или аналитиком пользовательских сценариев на естественном языке — если можно так выразиться, на языке бизнеса.
— BDD — просто модное слово или принципиально новый подход к разработке через тестирование? От TDD его отличает только использование естественных языков для описания тестов?
Юлия Ковалева: BDD и в самом деле модное слово, но далеко не все умеют его правильно «готовить». В «Альфа-Лаборатории» нам пришлось комплексно подойти к решению задач и полностью изменить многие аспекты функционирования всей команды, что позволило существенно удешевить процесс тестирования. Нанять умеющего описывать тестовые сценарии на русском языке человека намного проще, чем найти специалиста, способного реализовать эти тесты, например, на Java.
BDD подход совместно с инженерными практиками позволил нам отказаться от legacy-документации, содержащей неактуальную информацию, и получать новую документацию налету, хранить ее вместе с проектом, что позволило приблизить аналитиков и тестировщиков к коду.
— В разработку сценариев BDD вовлечены не только тестировщики, необходимость в автоматизаторах сохраняется?
Юлия Ковалева: Разумеется, оставить в команде только тестировщиков без автоматизаторов — достаточно недальновидно. Потребуется некий инструментарий и владеющий им человек, чтобы реализовать ту техническую составляющую, которую тестировщик самостоятельно сделать не сможет.
Анна Чернышева: Потребность команды в количестве экспертов по автоматизации тестирования уменьшается, поскольку есть фреймворки, которыми могут пользоваться тестировщики. Автоматизатор добавляет новую функциональность в тестовый фреймворк, и она сразу становится доступна всем командам.
— Помимо традиционных для TDD unit-тестов при использовании BDD-подхода проводятся также behavior-тесты. На этом различия процессов тестирования заканчиваются или дело обстоит сложнее?
Анна Чернышева: Все гораздо сложнее, поскольку BDD — скорее процесс, целью которого является удешевление реализации новых фич. Еще на старте разработки мы получаем важные артефакты. Например, понятную для поддержки документацию. Эта документация дает возможность всем заинтересованным лицам сформировать свое представление о продукте и сценариях пользовательского поведения, которые должны быть реализованы в ходе итераций разработки. С BDD-подходом мы также снижаем порог входа в проект новых участников.
— Многие считают, что BDD можно рассматривать как переход от основанной на unit-тестах разработки к разработке, основанной на интеграционном тестировании. А как ситуация обстоит на самом деле?
Юлия Ковалева: Мы провели такой эксперимент. Попытка использовать BDD-инструменты для написания unit-тестов успехом не увенчалась, через какое-то время разработчик отказался писать поведенческие тесты. Когда мы говорим про автоматизацию, BDD идеально вливается в эту историю, но применять такой подход к модульному тестированию не стоило, пользы нам это не принесло. При интеграционном тестировании польза от BDD будет значительной — здесь мы смотрим на весь продукт в целом.
— В каких случаях для тестирования применяется BDD подход и чем он лучше более традиционного TDD?
Анна Чернышева: BDD в основном используется для проверки взаимодействия разных компонентов системы, это, как уже было сказано, уровень интеграционного тестирования — оно поведенческое и проверяет различные бизнес-кейсы. TDD используется для разработки через модульное тестирование непосредственно программистами, которые пишут код через этот подход. В общем, если по-простому, TDD проверяет исключительно модули, а BDD — пользовательские сценарии.
— Зачем потребовались новые BDD-фреймворки, не проще оформить BDD в набор рекомендаций по написанию TDD и использовать существующие?
Юлия Ковалева: BDD появился, чтобы сделать команду разработки ближе к бизнесу, организовать диалог между бизнесом, разработчиками и тестировщиками. При TDD-подходе нужно писать тесты на формальных языках программирования. Тесты и код лежат в одном месте, их достаточно сложно поддерживать, а уж тестировщик или бизнес-аналитик едва ли полезет смотреть, что мы там написали. Два наиболее популярных BDD фреймворка — JBehave и Cucumber. Как их правильно применять, мы расскажем на ближайшей конференции Гейзенбаг 2017 Piter.
Анна Чернышева: Эта путаница между TDD и BDD пошла от общей для разных подходов идеи: сначала пишутся тесты, а потом идет разработка. При всех сходствах они предназначены для разных целей и требуют применения различных инструментов.
— То есть BDD нельзя считать расширением TDD?
Анна Чернышева: Да, мы считаем именно так. Вместо тестовой модели у нас есть пользовательские сценарии, которые мы автоматизируем в одном спринте с разработкой. Более того, в «Альфа-Лаборатории» BDD-подход органично внедрен и в инженерные практики.
— QA считают женской профессией. Как вы полагаете, с чем это связано и насколько соответствует действительности? Есть ли вообще в IT понятие женской и мужской профессии?
Анна Чернышева: Сейчас от этого стараются уйти, но женское мышление более абстрактно, а мужчинам важны конкретные детали — это, конечно, все индивидуально, но если брать «Альфа-Лабораторию», то девушек-тестировщиков в процентном соотношении несколько больше. Может, тестирование требует творческого подхода, а девушки — более творческие натуры?
Юлия Ковалева: Можно провести эксперимент и подсчитать, сколько девушек и мужчин придут на Гейзенбаг.
На Гейзенбаг 2017 Юлия Ковалева и Анна Чернышева сравнят Cucumber и JBehave. У какого BDD-фреймворка больше возможностей? Как их правильно «готовить» и с какими трудностями придется столкнуться во время тестирования — состязание ведущих разработчиков автотестов «Альфа-Лаборатории» пройдет в лучших традициях Mortal Kombat.
Полная программа конференции доступна на сайте.
Behavior-Driven Development
Как правильно определять требования к продукту или системе, чтобы результаты разработки совпадали с ожиданиями.
Это именно то, о чем я просил, но не то, что я хочу
Поэма «Ночь перед воплощением», автор неизвестен
Разработка на основе поведения (Behavior-Driven Development, BDD) — это практика Agile-тестирования, когда в первую очередь проводятся проверочные испытания, которые обеспечивают встроенное качество за счет определения (и, потенциально, автоматизации) тестов до или как часть определения поведения системы. BDD — это совместный процесс, который создает общее понимание требований между бизнесом и Agile-командами. Его цель — помочь в управлении разработкой, уменьшить количество переделок и увеличить поток. Не фокусируясь на внутренней реализации, тесты BDD представляют собой бизнес-сценарии, которые пытаются описать поведение пользователя с точки зрения Истории (Story), Фичи (Feature) или Возможности (Capability).
Будучи автоматизированными, эти тесты гарантируют, что система постоянно соответствует заданному поведению даже в процессе своего развития. Это, в свою очередь, позволяет выпускать Релиз по Потребности (Release on Demand). Автоматизированные тесты BDD могут также служить для формулирования поведения системы, в качестве встроенной в другую систему.
Как определить будущее поведение системы
При разработке инновационных систем сложно точно определить, что именно нужно создать. Кроме того, новые идеи трудно донести до широкого круга заинтересованных лиц, ответственных за внедрение системы. На рис. 1 показаны три точки зрения (называемые триадой), необходимые, для четкого определения поведения решения:
Рис. 1. Разнообразие восприятий, необходимое для определения объективного принятия решения
Вместе эта группа достигает согласованности в том, что именно нужно создавать, чтобы уменьшить количество ошибок и переделок и ускорить поток ценностей.
Процесс поведенческой разработки
Процесс BDD проходит три этапа — исследование (discovery: раскрытие проблемы клиента и ее решения), формулирование и автоматизация — где критерии приемки преобразуются в приемочные испытания, которые затем автоматизируются. Процесс начинается на этапе исследования, когда Владелец Продукта (Product Owner, РО) или Менеджер Продукта (Product Manager, PM) создает критерии приемки как часть написания Истории или Фичи. Процесс исследования является совместным, и члены команды также определяют и вносят дополнительные критерии.
По мере того, как элемент бэклога приближается к реализации, на этапе формулирования, критерии приемки закрепляются через создание приемочных тестов. Первоначальные критерии приемки часто описываются неопределенными общими терминами. Этап формулировки устраняет эти неясности, превращая сценарии в подробные приемочные тесты, которые представляют собой конкретные, четкие и однозначные примеры поведения.
На этапе автоматизации приемочные тесты автоматизируются, поэтому они могут проводиться непрерывно и проверять, что система всегда поддерживает актуальное поведение.
Задача BDD — однозначно выразить требования, а не просто создать тесты. Приемочные тесты служат для записи решений, принятых в ходе обсуждений между командой и Владельцем Продукта, чтобы команда однозначно понимала предполагаемое поведение продукта. Есть три альтернативных варианта для этого процесса детализации:
В подходах существуют небольшие различия, но все они подчеркивают необходимость понимания требований до их реализации.
Пример
Описание поведения начинается с Истории, Фичи или Возможности, указанных в критериях приемки. Все они определяются с использованием клиентских терминов, а не внедрения. Вот пример истории и критерии ее принятия:
Рис. 2. Пример истории и критерии приёмки
Критерии приёмки также могут быть записаны в формате «Given — When — Then» (GWT), как показано ниже:
Given (Дано) ограничение скорости
When (Когда) машина едет
Then (Тогда) скорость близка к предельной, но не выше.
Даже в этом случае разработанных критериев приёмки обычно недостаточно, чтобы оформить Историю. Чтобы устранить неопределенность, сформулируйте сценарий в виде одного или нескольких примеров, которые определяют детали поведения, что приведет к конкретному приемочному тесту:
Дано ограничение скорости — 80 км/ч
Тогда её скорость — от 78 до 80 км/ч.
В сотрудничестве с командой (триадой) появятся дополнительные критерии приёмки и сценарии, например: когда ограничение скорости меняется, скорость резко не меняется.
Этот критерий приводит к дополнительным тестам, которые определяют допустимую интенсивность замедления:
Дано ограничение скорости составляет 80 км/ч
Когда ограничение скорости изменяется до 50 км/ч
Тогда скорость должна снижаться менее чем на 5 км/ч за сек.
На рис. 3 показан процесс BDD, который начинается с Истории и детализирует ее спецификацию в двух измерениях. По горизонтали дополнительные критерии приёмки детализируют требования к истории. По вертикали дополнительные приемочные тесты детализируют эти требования к приемочным тестам.
Рис. 3. Процесс BDD детализирует поведенческие характеристики.
Автоматизация приемочных тестов
Приемочные тесты Истории пишутся и выполняются в той же итерации, что и разработка кода. Если История не проходит тесты, История не засчитывается команде. У Фич и возможностей есть свои собственные приемочные тесты, которые показывают, как несколько Историй работают вместе в более широком контексте. Как правило, эти тесты демонстрируют поведение более крупных сценариев рабочего процесса и должны выполняться во время итерации, в которой Фича или возможность завершены.
SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.
Опыт использования BDD
Около семи лет назад Dan North в своей статье описал практическое применение BDD подхода, который позволяет сделать процесс разработки более понятным и управляемым путем налаживания внутренних коммуникаций. Индустрия с каждым днем проявляет всё больший интерес к этой методологии, нацеленной на продуктивное взаимодействие стандартных команд типа «аналитика-разработка-тестирование».
Однако, сейчас лишь малая часть компаний решается на использование BDD. Почему?
Итак, давайте разберемся. BDD (Behaviour Driven Development — «Разработка через поведение») — гибкая методология, тесно связанная с TDD (Test Driven Development — «Разработка через тестирование»). По опыту, даже матерые тестировщики зачастую не видят разницы между этими методологиями. Действительно, на первый взгляд ее трудно вычленить: оба подхода предполагают написание документации и тестов до старта этапа разработки. А различие вот в чем: в BDD для описания тестов требуется использование естественного языка, понятного каждому участнику проекта, чтобы, фактически, объединить постановку задачи, тесты и документацию воедино. Другими словами, определяется DSL (специфичный предметно-ориентированный язык), потом составляется стандартный ограниченный набор фраз, описывающих поведение нужных элементов. Затем с их помощью разрабатывается сценарий использования новой функциональности, который будет понятен всем.
Давайте один раз увидим разницу, и она станет очевидной:
Мы еще коснемся этого примера, а для начала давайте посмотрим на все разнообразие методологий, которые на данный момент имеют ненулевую актуальность.
Сравним несколько методологий
Диаграмма ниже показывает сравнение трех подходов: TDD, TLD (Test Last Development) и BDD:
На второй диаграмме изображено вовлечение участников процесса разработки в написание сценариев.
Несомненно, BDD — это хороший инструмент, позволяющий достичь качества продукта. Тесты и документация пишутся быстрее. Для бизнеса проект становится более прозрачным, благодаря конструкциям естественного языка, понятным любому человеку, далекому от программирования.
Это о плюсах. Тем не менее, как уже было сказано, несмотря на большое количество плюсов, мало кто эту методологию внедряет.
BDD всем хорош, но почему его не используют?
Ответ прост: это долго и дорого. С этим утверждением согласятся большинство IT компаний. И поначалу мы не были исключением. BDD неудобен хотя бы тем, что требует привлечения специалистов тестирования уже на этапе проработки требований.
BDD переворачивает с ног на голову классическую схему ведения разработки (TLD). Она плохо реализуема, потому что это сложно. Удлиняется цикл разработки.
BDD — это несомненно способ достичь качества. Но не все готовы платить временем и специалистами за это качество.
Однако, что делать, если BDD все же хочется внедрить?
Можно попробовать использовать готовые фреймворки. Например Cucumber, Squish, Yulup.
Основная проблема сложности BDD не в процессе, а в реализации и существующих инструментах. Возьмем в качестве примера WEB разработку корпоративной информационной системы. Имея web реализацию мы сталкиваемся с WebDriver’ом являющимся в данный момент стандартом при автоматизации приложений, работающих в веб браузере. Он обладает довольно большими возможностями. Для учитывания различных кастомизаций элементов страницы необходимо придумывать варианты обращения к ним. И тут для облегчения разработки теста на помощь приходят различные библиотеки (Selenide, и др.), что создает свою экосистему, которую нужно знать. Для работы с WebDriver нужен программист либо тестировщик-автоматизатор, т.к. все реализуется с помощью кода и хитрых конструкций.
Начало работы с BDD фреймворком — сложно и долго
Наше внимание остановилось на инструменте под названием Gauge. Это гибкий и легковесный фреймворк, распространяющийся по свободной лицензии. Признаться честно, мы не особо изучали альтернативы, т.к. использование Gauge было настойчиво продиктовано нашим заказчиком.
Gauge позволил нам использовать плюсы BDD. Однако мы все равно столкнулись с проблемами, которые заключаются в сложности реализации: проблемы инструментария и внедрения процесса.
Оказалось, что привлечение тестировщиков на раннем этапе плохо сказывается на конечном результате. Увеличивается время на разработку тестов. При использовании любого фреймворка требуются большие усилия тестировщика, который, несомненно, хорошо должен владеть и программированием. Поначалу процесс работы со сценарием был следующим: аналитик рассказывал тест тестировщику, а записывал его технический писатель. Пока тестировщик разбирался с программной реализацией, изменялся смысл тестируемой функциональности. Тут сказывается разделение точки входа, а она должна быть одна, по итогу процесс разделяется и превращается в “обычный” процесс, от которого как раз и хотелось уйти. Т.е. точка входа разделилась, коммуникации расползлись, тестировщик ушел с головой в имплементацию теста, технический писатель понял как-то по своему, а аналитик уже и свои доки переписал и передумал, разработчик же вообще ушел в “свой мир” ).
Много времени у тестировщика уходило на код. А ведь еще тот же тестировщик должен был продумать поиск элементов на странице. Ситуация напоминала известную детскую игру: “Испорченный телефон”. Возникал коллапс. И мы решили: BDD будет работать только в том случае, если тесты смогут писать аналитики. Нужно снизить трудоемкость написания тестов, упростить их. Но для этого нужно существенно упрощать интерфейсы тестирования. Инструменты тестирования, реализация процесса в совокупности со всеми подходами и библиотеками должны быть проще.
Работа тестировщика вначале выглядела следующим образом:
Этот список кратко проиллюстрирован на диаграмме процесса разработки:
Наша компания специализируется на проектах с веб реализацией интерфейсов. Исходя из этого, мы используем инструмент Web Driver для взаимодействия с веб браузером.
Де-факто, Selenium Web Driver является стандартом, и он используется для описания веб объектов на любых фреймворках, в том числе Gauge, jUnit, библиотек Masquerade и других. Гибкости у него много для разных задач, что создает излишнюю трудоемкость в локально-типовых задачах. Нам нужно найти решение для уменьшения трудоемкости.
Для примера покажем на схеме — как связаны Selenium Web Driver, фреймворк Gauge, библиотека Masquerade, язык программирования Java.
В этой схеме можно вместо BDD фреймворка поставить jUnit, TestNG или любой другой, любая связка будет работать, в зависимости от потребностей. Selenium и Masquerade останется, язык программирования можно изменить.
Ускорение процесса написания кода — подключение Masquerade
В нашей компании разработка ведется на платформе CUBA. И специально для этой платформы был разработан инструмент для автотестов: Masquerade — библиотека, которая предоставляет лаконичный и удобный API для работы с кодом при имплементации тестов с использованием WebDriver. Эта библиотека работает над Selenium Web Driver, дружит с selenide и любыми фреймворками.
В CUBA проектах каждый элемент веб страницы содержит cuba-id, который не меняется. В CUBA используется компонентный подход, а библиотека Masquerade упрощает взаимодействие с элементами веб страницы. Библиотека умеет совершать действия с элементами веб страницы, реализованными с помощью CUBA, более простым образом. Поэтому при поиске элементов на странице не нужно использовать громоздкие конструкции с XPath, как было раньше:
Или более лаконичные конструкции на Java, которые, тем не менее, по-прежнему громоздки:
После подключения библиотеки Masquerade описание вложенного контрола выглядит просто и к нему легко обратиться. Можно даже не искать контрол на странице, т.к. в проекте он уже есть. Приведем пример описания кнопки для формы авторизации в приложении:
В коде страницы нам виден четко узнаваемый элемент cuba-id=”loginButton”
Опишем кнопку, используя библиотеку Masquerade:
Простой вариант реализации теста на фреймворке jUnit — блок авторизации, который выполняется перед каждым тестом:
А в теле метода login следующий код:
При этом самое важное — то, как мы описываем страницу, как мы обращаемся к элементам. Описание страницы LoginWindow:
Поиск элементов — это лишь часть возможностей библиотеки Masquerade. Обращение к элементам веб страницы позволяет совершать различные действия с этими элементами. Например, можно выбрать элемент из выпадающего списка:
Или отсортировать таблицу:
Список некоторых действий с таблицей смотрите на скриншотах ниже:
Использование Masquerade значительно упростило написание тестов, теперь, чтобы написать тест для новой функциональности, нужно:
Интегрируем Masquerade и Gauge
До использования BDD, применялся подход TLD и для работы с ним мы также оптимизировали процесс написания кода тестов. Использовали связки jUnit/TestNG + WebDriver+Selenide+Masquerade.
Теперь, для того, что бы работать с Gauge, добавляем соответствующий плагин в intellij IDEA. После этого появится возможность создавать новый тип тестов — Specification.
Теперь создаем спецификацию (сценарий) и имплементируем шаги, используя возможности WebDriver, Masquerade и Java.
Кликаем на шаг сценария и переходим в имплементацию:
В имплементации можно использовать уже существующий метод login().
Как же выглядит это совершенство?
Вспомним пример, который мы рассматривали в самом начале статьи:
«Navigation.openMenu(menu)” содержит реализацию открытия меню с помощью библиотеки Masquerade.
Библиотека впоследствии была расширена и появились универсальные шаги, которые могут быть использованы для любого CUBA-приложения. Это шаги, позволяющие работать с элементами программы: кнопками, полями, таблицами. Эти универсальные шаги и стали тем набором стандартных фраз, которые мы используем в BDD для написания сценариев.
Благодаря связке Masquerade+Gauge мы существенно снизили трудоемкость создания тестов. Теперь тесты могут писать люди, не имеющие особых навыков программирования. Тест может писать один человек (раньше сценарий придумывал один, а реализовывал — другой, что приводило к путанице). Итак, мы добились своей цели — интерфейсы упрощены, а аналитикам не составит труда писать тестовые сценарии.
Изменения процесса изображены ниже:
Стало:
В сравнении видно, что требования, спецификация и тест документация объединены в один пункт. Тест документация является и автотестом, за исключением имплементации специфичных тестовых шагов.
Итоги
На данный момент мы успешно ведем разработку по обозначенной выше схеме. И нам удалось избавиться от главной проблемы BDD — серьезного увеличения сроков из-за сложности реализации, добавив и доработав инструментарий. Однако, качество выдачи продуктов улучшилось.
Временные затраты на поддержку документации сокращаются пропорционально количеству измененных спецификаций, т.к. одно изменение спецификации (логики системы) приводит автоматически к изменению автотеста за одну итерацию. Т.е. тестировщику не нужно лезть в систему документации (типа Confluence и т.д) для апдейта, и для других участников команды это тоже справедливо.
В разработке любого бизнес решения и в управлении качеством — стоимость устранения ошибок сбора требований и анализа растет экспоненциально. Соответственно вероятность получения проблем, связанных с переделкой продукта, согласно существующим статьям и графикам при итеративной разработке, при раннем обнаружении проблемы, которая заключается в хорошей проработке требований, существенно снижает стоимость разработки, в зависимости от проекта. Это может быть и 0% и
40%. Именно это улучшение достигается за счет внедрения BDD. Это можно внедрить и не называя это словом BDD, но в BDD оно есть. Наличие возможности обойти проблемы является важной частью обеспечения качества.
В завершение, хотелось бы отметить, что данная схема разработки также интегрирована у нас с Continuous Integration и разработанной в нашей компании системой тест менеджмента — QA Lens. В QA Lens можно писать те же сценарии, что и в IDEA, используя предметно-ориентированный язык. Этот язык состоит из ранее составленного глоссария доступных действий, которые ранее имплементированы. При выполнении автотеста на Gauge с машины разработчика или CI — в QA Lens автоматически отмечается: какие шаги сценариев были пройдены, а какие нет. Таким образом, прогнав автотест сценария, написанного аналитиком, отдел тестирования сразу получает полную актуальную информацию о состоянии продукта.
Авторы: Сунагатов Ильдар и Юшкова Юлия (Yushkova)
