60 lines
6.8 KiB
Markdown
60 lines
6.8 KiB
Markdown
|
---
|
|||
|
|
title: Behavior Driven Development
|
|||
|
|
localeTitle: Разработка поведения
|
|||
|
|
---
|
|||
|
|
## Разработка поведения
|
|||
|
|
|
|||
|
|
Разработка поведения (BDD) - это процесс разработки программного обеспечения, который появился из  , Behavior Driven Development сочетает в себе общие методы и принципы TDD с идеями, основанными на доменном дизайне и объектно-ориентированном анализе и дизайне, для создания групп разработки программного обеспечения и управления с использованием общих инструментов и совместного процесса для совместной работы по разработке программного обеспечения. Это методология разработки программного обеспечения, в которой приложение определяется и конструируется, описывая, как его поведение должно появляться внешнему наблюдателю.
|
|||
|
|
|
|||
|
|
Хотя BDD - это в основном идея о том, как управление разработкой программного обеспечения должно осуществляться как с деловыми интересами, так и с технической точки зрения, практика BDD предполагает использование специализированных программных средств для поддержки процесса разработки.
|
|||
|
|
|
|||
|
|
Хотя эти инструменты часто разрабатываются специально для использования в проектах BDD, их можно рассматривать как специализированные формы инструментария, поддерживающего разработку, основанную на тестах. Инструменты служат для добавления автоматизации к вездесущему языку, который является центральной темой BDD.
|
|||
|
|
|
|||
|
|
BDD фокусируется на:
|
|||
|
|
|
|||
|
|
* С чего начать в процессе
|
|||
|
|
* Что тестировать и что не тестировать
|
|||
|
|
* Сколько нужно проверить за один раз
|
|||
|
|
* Что нужно назвать испытаниями
|
|||
|
|
* Как понять, почему тест не прошел
|
|||
|
|
|
|||
|
|
В основе BDD лежит переосмысление подхода к тестированию устройств и приемочным испытаниям, которые, естественно, возникают с этими проблемами. Например, BDD предлагает, чтобы имена единичных тестов были целыми предложениями, начиная с условного глагола (например, «should» на английском языке) и должны быть записаны в порядке ведения бизнеса. Приемочные тесты должны быть написаны с использованием стандартной гибкой структуры пользовательской истории: «В _роли_ я хочу использовать _функцию,_ чтобы _получить выгоду_ ». Критерии приемлемости должны быть записаны с точки зрения сценариев и реализованы в виде классов: при _исходном контексте_ , когда _происходит событие_ , затем _обеспечивайте некоторые результаты_ .
|
|||
|
|
|
|||
|
|
пример
|
|||
|
|
```
|
|||
|
|
Story: Returns go to stock
|
|||
|
|
|
|||
|
|
As a store owner
|
|||
|
|
In order to keep track of stock
|
|||
|
|
I want to add items back to stock when they're returned.
|
|||
|
|
|
|||
|
|
Scenario 1: Refunded items should be returned to stock
|
|||
|
|
Given that a customer previously bought a black sweater from me
|
|||
|
|
And I have three black sweaters in stock.
|
|||
|
|
When he returns the black sweater for a refund
|
|||
|
|
Then I should have four black sweaters in stock.
|
|||
|
|
|
|||
|
|
Scenario 2: Replaced items should be returned to stock
|
|||
|
|
Given that a customer previously bought a blue garment from me
|
|||
|
|
And I have two blue garments in stock
|
|||
|
|
And three black garments in stock.
|
|||
|
|
When he returns the blue garment for a replacement in black
|
|||
|
|
Then I should have three blue garments in stock
|
|||
|
|
And two black garments in stock.
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
Наряду с этим есть некоторые преимущества:
|
|||
|
|
|
|||
|
|
1. Все работы по развитию можно проследить непосредственно до бизнес-целей.
|
|||
|
|
2. Разработка программного обеспечения отвечает потребностям пользователей. Довольные пользователи = хороший бизнес.
|
|||
|
|
3. Эффективная приоритизация - прежде всего, доставляются важные для бизнеса функции.
|
|||
|
|
4. Все стороны имеют общее понимание проекта и могут участвовать в сообщении.
|
|||
|
|
5. Общий язык гарантирует, что каждый (технический или нет) имеет полную видимость в продвижении проекта.
|
|||
|
|
6. Результирующий дизайн программного обеспечения, который соответствует существующим и поддерживает будущие потребности бизнеса.
|
|||
|
|
7. Улучшенный код качества, снижающий затраты на обслуживание и минимизирующий риск проекта.
|
|||
|
|
|
|||
|
|
## Больше информации
|
|||
|
|
|
|||
|
|
* Wiki на [BDD](https://en.wikipedia.org/wiki/Behavior-driven_development)
|
|||
|
|
* Известной структурой разработки, основанной на поведении (BDD) является [Cucumber](https://cucumber.io/) . Огурец поддерживает многие языки программирования и может быть интегрирован с несколькими структурами; например, [Ruby on Rails](http://rubyonrails.org/) , [Spring Framework](http://spring.io/) и [Selenium](http://www.seleniumhq.org/)
|
|||
|
|
* https://inviqa.com/blog/bdd-guide
|