Погрузитесь в мир разработки программного обеспечения с BDD и TDD — методологиями, которые гарантируют высокое качество и соответствие продукта ожиданиям пользователя.

Разработка через тестирование (Test-driven development) – это метод разработки, который подразумевает постоянное повторение коротких циклов разработки. Данный подход был создан и описан американским разработчиком Кентом Беком. Суть его заключается в следующем:

На первом этапе цикла пишется тест для функции, которую мы хотим использовать в программном продукте. Следующий шаг подразумевает написание кода, позволяющего пройти данную проверку. Завершает цикл проведением рефакторинга кода по отношению к установленным требованиям. Процедуры будут повторяться до тех пор, пока продукт не будет готов к эксплуатации.

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

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

Разработка через тестирование имеет ряд преимуществ, которые были отмечены многими специалистами, а именно:

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

• Данный метод позволяет не только проверять продукт на баги на ранних этапах разработки, но и влиять на его дизайн и архитектуру. Таким образом, получится написать более выверенный и чистый код.

• При создании тестов разработчик предполагает модели поведения пользователей, то есть то, как именно в конечном итоге они будут взаимодействовать с программным продуктом.

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

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

• Метод TDD позволяет разработчикам чувствовать себя увереннее и работать более эффективно, потому что при внесении изменений в продукт, его функционал не пострадает.

• Разработка через тестирование делает код более гибким, а это значит, что можно поддерживать высокий уровень актуальности и конкурентоспособности продукта. С точки зрения разработчика, программа является набором модулей, которые прошли тщательную проверку и лишь после этого были объединены в единое целое.

• Автоматизированные тесты могут покрыть все пути исполнения.

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

Есть и свои отрицательные нюансы, которые также стоит учитывать, если компания планирует внедрить метод TDD в свою работу. А именно:

• Не все типы задач решаются с помощью тестов. Чистый код менее уязвим, поэтому более безопасн. Однако существуют некоторые тонкости, требующие вмешательства человека.

• Разработка через тестирование рассчитана лишь на небольшой объем работы, то есть ее удобнее применять для отдельно взятых модулей, а не целиком к продукту. Например, при разработке интерфейса для пользователя TDD не подойдет.

• Компания должна быть уверена, что данный метод разработки действительно позволит им улучшить код. В противном случае это лишь отнимет время у программистов.

• Обычно данный метод подразумевает, что человек, который пишет модульные тесты, также пишет тестируемый код. Поэтому он может не заменить своей собственной ошибки, если она возникнет.

• Наличие большого числа тестов не гарантирует надёжность и высокое качество продукта, если сами тесты были излишне сложными или в принципе неуместными.

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

Eclipse.

Это многофункциональная среда разработки с возможностью поддержки большого количества языков программирования. Особенную любовь к ней питают в Jawa–комьюнити. Такая любовь обоснована тем, что Eclipse постоянно проходит проверку под новые релизы Java, поэтому разработчики всегда имеют свежие версии в числе первых.

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

Eclipse имеет нативную поддержку JUnit.

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

Полная версия JUnit имеет три встроенных плагина: JUnit Platform – выступает в качестве основного модуля по управлению тестами; JUnit Jupiter – использует возможности Jawa 8, а также может работать с модульными и динамическими тестами; JUnit Vintage – обеспечивает поддержку тестов с применением JUnit 3 и JUnit 4.

MoreUnit – плагин, призванный помочь в написании дополнительных тестов для модулей. Поддерживает все языки программирования, особенно Java, может переключаться между тестами и классами, поддерживает рефакторинг и многое другое.

Infinitest – используется для непрерывного тестирования Java. Наибольшую пользу принесет тем разработчикам, которые используют JUnit.

Оба плагина Eclipse используют для управления юнит–тестированием. Они автоматически проводят проверку кода при каждом его изменении. По сути, это ускоряет цикл TDD.

Moq.

Легкий и незамороченный, изолированный фреймворк. Он основан на анонимных методах и деревьях выражений. Чтобы создавать моки, он применяет кодогенерацию, что дает ему возможность «мокать» интерфейсы и виртуальные методы, но обходит стороной невиртуальные и статические методы.

Apache JMeter.

Java–приложение для проведения нагрузочного тестирования функционала приложений и оценки производительности тестов. Имеет поддержку протоколов LDAP. Совместим с такими базами данных, как JDBC или FTP. Может непрерывно интегрироваться при помощи Gradle, Maven и Jenkins. В целом имеет широкий спектр возможностей, позволяющий Apache JMeter проводить проверку веб–приложений, динамических и статистических приложений.

Mockito.

Помогает в создании объект–макета для целей тестирования. Благодаря ему удается упростить процесс изоляции зависимостей во время проверки кода. Также фреймворк помогает в имитации внешних зависимостей. В общем и целом, очень полезный TDD–инструмент.

Разработка на основе поведения является ответвлением от TDD и одной из практик Agile–разработки. По сути, создание программного продукта строится вокруг проверенных сценариев поведения пользователей. То есть и TDD, и BDD призывают создавать документацию и тесты до начала разработки. Behaviour Driven Development подразумевает полную трансформацию процесса создания программного продукта со своими принципами, правилами, участниками и инструментами.

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

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

При работе с методом BDD количество разного рода документации сокращается. Например, спецификация выступает в качестве и автотеста, и тестового сценария. Как минимум работа тестировщиков становится проще.

Заказчик лучше понимает, за что платит, для него процессы разработки становятся более прозрачными и понятными. Соответственно, и для команды разработчиков он будет более полезен с точки зрения источника первичной информации.

Среди IT–специалистов считается, что Behaviour Driven Development–метод является достаточно долгим и трудозатратным, поэтому он не имеет популярности, несмотря на свои достоинства.

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

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

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

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

В случае с Behaviour Driven Development основной упор делается на те инструменты, которые помогают создавать сценарии для проверки поведения пользователя при взаимодействии с продуктом.

Среди специализированных фреймворков можно назвать Cucumber.

Он дает возможность перевести сценарии в формат текстовых спецификаций на основе языка Gherkin. Также он совместим со многими языками программирования, в том числе Java, JavaScript и Ruby. В платной версии имеет более широкие возможности для команды, а также может взаимодействовать с Jira.

FitNesse является коробочным решением с открытым кодом.

Его используют для тестирования JavaScript, а именно для приемочного тестирования продукта. Он не нуждается в предварительной установке и настройке, достаточно лишь запустить jar–файл и отправить его на браузер и оборудование, где будет осуществляться работа.

Behat используется для PHP–тестирования.

Как и предыдущий фреймворк, он также имеет открытый код. Для написания сценариев он использует все тот же Gherkin язык, что и Cucumber. За счет различных расширений его функциональность расширяется и улучшается. Чаще всего Behat применяют при кросс–браузерном тестировании. В нем отсутствует зависимость от операционной системы.

Безусловно, выбор BDD–фреймворков значительно больше. Каждый из них заточен под разные задачи, хотя есть и достаточно универсальные решения, к тому же с открытым кодом. Это позволяет трансформировать продукт под свои запросы и добиваться ожидаемого результата.

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

• Фокус внимания и перспектива.

TDD – функционал реализуется на основе результатов первого тестирования.

BDD – определение функционала происходит на основе представлений о поведении конечного пользователя.

• Удобочитаемость и используемая терминология.

TDD – тесты и спецификации пишутся с использованием специфической терминологии и ориентированы прежде всего на команду разработки.

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

• Сотрудничество и коммуникация.

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

BDD – в проект вовлекаются все заинтересованные лица, которые могут быть полезны в процессе разработки. На этапе тестирования привлекаются владельцы продукта, чтобы они проверяли программу или приложение с точки зрения пользователя и оценили соответствие всем требованиям.

• Степень абстракции.

TDD – наибольшее внимание уделяется низкоуровневым модульным тестам, с помощью которых проверяется поведение отдельных блоков.

BDD – в этом случае наоборот фокус внимания сдвинут на высокоуровневые модульные тесты, которые имитируют поведение пользователей.

• Организация тестирования.

TDD – в основе теста находится структура кода, иерархический и модульный подход.

BDD – чаще всего сценарии тестов сгруппированы по функциям.

• Цель.

TDD – корректность кода достигается за счет автоматизации тестов.

BDD – позволяет лучше понимать концепцию в целом, улучшает коммуникацию и проводит проверку системы.

• Рабочий процесс.

TDD – тесты пишутся непосредственно перед реализацией кода.

BDD – сценарии определяются перед внедрением кода.

• Области применения тестов.

TDD – в большинстве случаев фокусируется на проверке отдельных единиц кода.

BDD – имеет широкий охват, который сосредоточен на разных единицах кода.

• Стиль.

TDD – технически ориентирован с фокусом на реализацию.

BDD – все строится вокруг пользователя и его модели поведения.

• Детализация теста.

TDD – отдельные блоки проверяются изолированно.

BDD – детальное исследование системы программного продукта в целом.

• Итеративная доработка и обратная связь.

TDD – уточнение и проверка кода происходят в рамках коротких итераций, после чего осуществляется его модификация.

BDD – уточнение и написание сценариев происходит в рамках коротких итераций путем общей работы команды и прочих заинтересованных лиц.

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