В прошлом менеджмент качества тратил недели на проверку функциональности готового программного обеспечения. Благодаря автоматизированным тестам теперь можно узнать, выполняет ли сложное приложение свои задачи без проблем, одним нажатием кнопки. Все более популярной техникой является разработка, ориентированная на поведение, или сокращенно BDD. Эта форма гибкой разработки программного обеспечения возникла на основе разработки, управляемой тестами (TDD), и считается ее логическим продолжением. Однако, в отличие от TDD, BDD в первую очередь рассматривает соответствующую программу с точки зрения пользователя. Этот подход способствует более целостному проектированию программного обеспечения и упрощает сотрудничество между разработчиками, менеджерами по качеству и клиентами.
Что такое разработка, ориентированная на поведение?
Поскольку требования к программному обеспечению становятся все более сложными, разрабатывается все большее количество методов управления качеством и тестирования. Они необходимы для того, чтобы надежно проверять функциональность отдельных компонентов и своевременно обнаруживать ошибки. Разработка, управляемая тестами (TDD), когда разработчики готовят подходящие модульные или системные тесты в дополнение к созданию программного обеспечения, существует уже некоторое время. Однако при разработке программного обеспечения часто бывает полезно привлекать не только программистов, но и членов команды или заинтересованных лиц, не имеющих технических навыков кодирования. Поведенчески-ориентированная разработка (BDD) делает это возможным.
В ходе гибкой разработки программного обеспечения все участники проекта могут определить желаемое поведение приложения до того, как программист создаст исходный код. Этот процесс включает в себя описания, составленные на понятном для людей языке. Это означает, что заказчик может играть активную роль в моделировании собственного программного обеспечения. Таким образом, BDD способствует сотрудничеству и делегированию ответственности. При правильном использовании этого типа разработки программного обеспечения вы сможете избежать недопонимания с самого начала и создать более качественный конечный продукт.
Как именно работает разработка, ориентированная на поведение?
Как следует из названия, разработка с учетом поведения основывается на желаемом поведении соответствующего программного обеспечения. Благодаря повсеместно распространенному языку, неспециалистам легко подготовить описание определенного поведения. Вездесущий язык пришел из доменно-ориентированного проектирования (DDD), которое, как и BDD, фокусируется на доменах приложений. Оба подхода учитывают все области разработки программного обеспечения и объединяют их независимо от фреймворков, языков программирования или инструментов. Использование единого языка делает это возможным.
Тем не менее, даже поведенчески-ориентированная разработка не может полностью обойтись без инструментов и фреймворков. Это связано с тем, что для того, чтобы определенные вами тестовые случаи были переведены в исполняемый код, необходимо следовать нескольким правилам. Например, описания в BDD не составляются в виде свободного текста. Используя такие инструменты BDD, как JBehave, Cucumber или Behat, вы можете следовать заданной структуре, которая обеспечивает правильную реализацию. Работать с этими инструментами гораздо проще, чем изучать обычный язык программирования. Ниже приведена иерархическая структура, которой вы обычно следуете при разработке, ориентированной на поведение:
- Во-первых, проведите анализ требований, в ходе которого вы точно определите задачи, цели и функциональные возможности программного обеспечения. Спросите себя или заказчика, что должно уметь делать программное обеспечение.
- После того как вы определили все функциональные возможности, они описываются в виде предопределенных сценариев. Попытайтесь представить все возможные сценарии, при которых программное обеспечение должно дать определенный ответ.
- Затем укажите ожидаемый ответ для каждого сценария в плане «Дано — Когда — Когда». «Дано» описывает программное обеспечение до теста, «Когда» — действия во время теста, а «Тогда» — состояние программного обеспечения после текста.
В зависимости от того, какой инструмент BDD вы используете, словарный запас может немного отличаться, хотя принцип один и тот же. Кстати, эти инструменты доступны для наиболее распространенных языков программирования, таких как Java, JavaScript, Python или Ruby.
Поведенчески-ориентированная разработка: пример из практики
Представьте, что вы хотите разработать удобный для пользователей интернет-магазин. После того как покупатель зарегистрировался в вашем магазине, его пользовательские данные должны быть сохранены. Таким образом, они смогут входить в магазин так часто, как захотят, без необходимости повторно вводить свои личные данные. На популярном языке Gherkin, используемом в BDD-инструменте Cucumber, правильный синтаксис будет выглядеть следующим образом:
Functionality: An existing customer should be able to log into their user account with their access data
Scenario: Customer enters the correct access data for the login process
Given I have a valid user account
And I am on the login webpage
When I enter my email address in the email field
And I enter my associated password in the password field
And I click on the login button
Then I should be automatically logged inПриведенный выше пример показывает, что вы можете использовать дополнение «And», чтобы перечислить несколько условий и сделать ваши тестовые случаи более сложными.
Чем BDD отличается от других процедур тестирования?
При тестировании программного обеспечения разработка, ориентированная на поведение, занимается вопросом «Как?». Участники хотят знать, как они могут правильно протестировать поведение кода, а не его реализацию. В отличие от этого, в случае модульного тестирования основное внимание уделяется определению того, правильно ли реализована отдельная единица кода. Поэтому данная процедура тестирования имеет дело с вопросом «Что?» и является быстрым способом поиска отдельных ошибок. На вопрос «Когда?» отвечает разработка, управляемая тестами, которая представляет собой процесс выполнения тестов. Этот процесс может также включать модульные тесты или другие методы тестирования.
Помимо модульных тестов, существуют также интеграционные и функциональные тесты. Они несколько сложнее, поскольку имеют дело с взаимодействием различных частей системы и общей функциональностью программы.
В приведенной ниже таблице вы найдете краткое описание преимуществ и недостатков разработки, ориентированной на поведение:
| Преимущества | Недостатки |
|---|---|
| Идеально подходит для начинающих благодаря вездесущему языку, не требуя предварительных знаний. | Плохо написанные спецификации усложняют работу разработчиков |
| Лучшая коммуникация между разработчиками, заинтересованными сторонами и менеджерами по качеству | Вовлечение нескольких сторон приводит к увеличению сроков разработки |
| Тестовые примеры служат живой документацией и могут быть легко скорректированы | Переход на BDD требует больших усилий, чем при работе с устаревшим кодом |
| Основное внимание уделяется конечным пользователям и удобству использования программного обеспечения |
Хотя вы можете применять каждую процедуру тестирования по отдельности, качество вашего программного обеспечения значительно улучшится, если вы объедините несколько методов тестирования. В случае BDD вы определяете лучший подход при написании тестов, а TDD обеспечивает высокое тестовое покрытие.