Comments 15
Во-первых было бы неплохо привести ссылку на оригинал, во вторых — статья не нова, да и на хабре не раз обсуждалась данная тема. Извините.
Ссылка на оригинал средствами хабра указывается внизу статьи обычно, этот случай не исключение.
Ссылка есть на обычном месте — внизу статьи нажимаете на имя автора.
Да, действительно статья довольно старая (несколько лет ей), но она именно вводит это понятие, BDD. Дон Нортон описывает, что его привело к этому, с какими проблемами он столкнулся. Он описывает те принципы, которые заложены до сих пор в этой методологии. Статья ценна этим, ведь лучше человека, который открыл этот метод, никто не расскажет.
Мне эта статья помогла уложить по полочкам все то, что лежит в этом подходе. Раньше я скептически к этому относился и использовал неправильно BDD — вносил множество деталей. Теперь я лучше понимаю этот подход.
Надеюсь она поможет и другим.
Да, действительно статья довольно старая (несколько лет ей), но она именно вводит это понятие, BDD. Дон Нортон описывает, что его привело к этому, с какими проблемами он столкнулся. Он описывает те принципы, которые заложены до сих пор в этой методологии. Статья ценна этим, ведь лучше человека, который открыл этот метод, никто не расскажет.
Мне эта статья помогла уложить по полочкам все то, что лежит в этом подходе. Раньше я скептически к этому относился и использовал неправильно BDD — вносил множество деталей. Теперь я лучше понимаю этот подход.
Надеюсь она поможет и другим.
Спасибо за статью. Раз уж в заголовке есть слово «введение» позволю себе нубский вопрос к аудитории. Мы довольно давно подсели на agile, но вот дзен все никак не наступит. Вцелом получается, что как только мы начинаем писать не технические истории, а именно behavior (As X I want Y so that Z) и пытаемся протянуть все до уровня тестов, получаются два неприятных эффекта:
1) Очень много головняка вываливается на сторону PO, вплоть до полной стагнации работы (даже в маленькой команде 3-5 чел). На достаточно простой технический сценарий получается куча As… I want… so that… историй настолько гранулярных, что за деревьями перестает быть виден лес. Фактически PO вынужден прорабатывать логику поведения в очень мелких деталях. Команда-то рада до соплей, потому что «перевести в тесты и дальше TDD», а вот PO и архитектор глубоко несчастны. Писать behavioral истории чтобы потом декомпозировать их в технические таски как-то уж слишком утомительно. Груминг требует дофига времени и вообще value от этой деятельности как-то не видно.
2) Так как за behavioral историями не видно ни дизайна, ни концепций, команда начинает буферить по-страшному. Велосити в стори-поинтах прет в гору, а реальный прогресс по фичам ни к черту ни годится. На бурндауне же видится такая типовая картина: behavioral истории висят в активном состоянии несколько дней и потом закрываются «пучками», т.е. пишут по факту одну фичу на несколько историй. Что мега раздражает всех, потому как усилия на прописывание историй получается тратятся зря…
При составлении беклога в виде технических историй такой фигни (параллельный проект) происходит меньше…
Что я делаю не так?
1) Очень много головняка вываливается на сторону PO, вплоть до полной стагнации работы (даже в маленькой команде 3-5 чел). На достаточно простой технический сценарий получается куча As… I want… so that… историй настолько гранулярных, что за деревьями перестает быть виден лес. Фактически PO вынужден прорабатывать логику поведения в очень мелких деталях. Команда-то рада до соплей, потому что «перевести в тесты и дальше TDD», а вот PO и архитектор глубоко несчастны. Писать behavioral истории чтобы потом декомпозировать их в технические таски как-то уж слишком утомительно. Груминг требует дофига времени и вообще value от этой деятельности как-то не видно.
2) Так как за behavioral историями не видно ни дизайна, ни концепций, команда начинает буферить по-страшному. Велосити в стори-поинтах прет в гору, а реальный прогресс по фичам ни к черту ни годится. На бурндауне же видится такая типовая картина: behavioral истории висят в активном состоянии несколько дней и потом закрываются «пучками», т.е. пишут по факту одну фичу на несколько историй. Что мега раздражает всех, потому как усилия на прописывание историй получается тратятся зря…
При составлении беклога в виде технических историй такой фигни (параллельный проект) происходит меньше…
Что я делаю не так?
Звучит так, как будто вы не делите истории на сценарии, а оставляете только мелкие сценарии-истории. Может быть истории слишком детальны?
Возможно. Фактически получается так:
Техническая история будет выглядеть приблизительно так: «сделать справочник правил для расчета компенсаций по целям продаж для сотрудников». К этой истории будет идти описание на пол-страницы какие поля должны быть в справочнике, и как по нему считается зарплата. Понятно, она связана за всем остальным и не вполне отражает взаимодействие с пользователем. Это неприятность. Однако она описана в терминах предметного домена, понятна аналитику и т.д. Да и получается довольно компактно, дев может в нее въехать за короткое время.
Если я пытаюсь написать то же с точки зрения BDD, я «попадаю» на описание всего этого с точки зрения актеров, т.е. «как администратор я хочу завести правило так что...» и дальше детализирую его. Но проблема в том, что этот справочник цепляет несколько «поведений» у трех разных ролей — и завести правило, и посмотреть, и выплатить и т.д. Т.е. скорее описывает процесс использования софта, нежели алгоритм его работы.
Или есть какие-то трюки для таких ситуаций?
Техническая история будет выглядеть приблизительно так: «сделать справочник правил для расчета компенсаций по целям продаж для сотрудников». К этой истории будет идти описание на пол-страницы какие поля должны быть в справочнике, и как по нему считается зарплата. Понятно, она связана за всем остальным и не вполне отражает взаимодействие с пользователем. Это неприятность. Однако она описана в терминах предметного домена, понятна аналитику и т.д. Да и получается довольно компактно, дев может в нее въехать за короткое время.
Если я пытаюсь написать то же с точки зрения BDD, я «попадаю» на описание всего этого с точки зрения актеров, т.е. «как администратор я хочу завести правило так что...» и дальше детализирую его. Но проблема в том, что этот справочник цепляет несколько «поведений» у трех разных ролей — и завести правило, и посмотреть, и выплатить и т.д. Т.е. скорее описывает процесс использования софта, нежели алгоритм его работы.
Или есть какие-то трюки для таких ситуаций?
Техническая история будет выглядеть приблизительно так: «сделать справочник правил для расчета компенсаций по целям продаж для сотрудников».
Странное сочетание — техническая история. Видимо, это не история, а задание для дева. С моей точки зрения, истории описываются со стороны тех актеров, пользователей системы.
Но проблема в том, что этот справочник цепляет несколько «поведений» у трех разных ролей — и завести правило, и посмотреть, и выплатить и т.д.
Хм, ну, а почему бы не использовать одно поведение в трех разных историях? Или создать одну роль объединяющую это поведение. Не понятно в чем проблема.
Т.е. скорее описывает процесс использования софта, нежели алгоритм его работы.
Что-то это тоже звучит странно. Здесь, видимо, какое-то смешение работы интерфейса и бизнес логики.
И потом, видимо, BDD не стоит использовать для детального описания вообще всех требований к системе (ваш справочник со всеми полями), а стоит разделять действительные правила от бизнес политик. Это хорошо описано у Томаса и Ханта в Прагматичном программисте. Может быть здесь что-то зарыто у вас?
Мы столкнулись с чем-то похожим.
Когда количество тестов по разным компонентам перевалило за тройку десятков и пошёл очередной рефакторинг, поскольку постоянно стал появляться копипаст, вышла просто адская работа. Такое ощущение, что каждая новая итерация усложняется экспоненциально.
В итоге лично я пришёл к мнению, что BDD — не оправдывает возлагаемых на него надежд. Почему? Потому что уходит слишком много ресурсов на поддержание прослойки между Gherkin и реальным тестом, чтобы всё это оставалось в приличном виде.
Возможно, выборочно ещё имеет смысл покрыть поведенческими тестами код, но только для случаев, когда разрабатывается такая логика системы, которую часто нужно согласовывать с бизнесом, скажем права доступа к объектам в зависимости от роли пользователя. Тогда удобно использовать листинг поведенческих тестов при очередном обсуждении.
А когда такой необходимости — лучше использовать классические юнит-тесты.
Когда количество тестов по разным компонентам перевалило за тройку десятков и пошёл очередной рефакторинг, поскольку постоянно стал появляться копипаст, вышла просто адская работа. Такое ощущение, что каждая новая итерация усложняется экспоненциально.
В итоге лично я пришёл к мнению, что BDD — не оправдывает возлагаемых на него надежд. Почему? Потому что уходит слишком много ресурсов на поддержание прослойки между Gherkin и реальным тестом, чтобы всё это оставалось в приличном виде.
Возможно, выборочно ещё имеет смысл покрыть поведенческими тестами код, но только для случаев, когда разрабатывается такая логика системы, которую часто нужно согласовывать с бизнесом, скажем права доступа к объектам в зависимости от роли пользователя. Тогда удобно использовать листинг поведенческих тестов при очередном обсуждении.
А когда такой необходимости — лучше использовать классические юнит-тесты.
«А мальчик Валентин потом это слово в словаре нашел, и так оно ему в душу запало, что стал он впоследствии главным специалистом по бихевиоризму.»
Стал читать, сразу наткнулся:
CustomerLookup
finds customer by id
fails for duplicate customers
Прим. «CustomerLookup [поиск заказчика]: находит заказчика по ID, не находит повторяющихся заказчиков,..»)
Не «не находит», а падает (тест), если есть несколько одинаковых заказчиков.
CustomerLookup
finds customer by id
fails for duplicate customers
Прим. «CustomerLookup [поиск заказчика]: находит заказчика по ID, не находит повторяющихся заказчиков,..»)
Не «не находит», а падает (тест), если есть несколько одинаковых заказчиков.
Сейчас применяю TDD в свой проекте. Проект на C++. Также есть опыт работы по TDD в Java-проекте.
Скажу что это земля и небо. Попытаюсь пояснить свои мысли:
1) Современные Java IDE позволяют очень быстро перейти от production к unit-test и обратно, как правило это одна горячая клавиша у меня в NetBeans это ctrl+shift+'t'
2) В Java IDE тесты выполняются быстрее чем в C++. Потому что в С++ любая часть кода от которой зависит тестируемый production код должна быть скомпилирована. Насколько понял, а я в Java не большой знаток, там в Java не все компилируется, а только то что нужно для выполнения
Из чего выводы:
Чтобы прикручивать Unit-тесты в C++ проекты мне приходится дробить на более мелкие проекты, а это время! Т.е. время затрачиваемое на работу по TDD в C++ проектах значительно больше чем в Java-проектах.
Может быть неправильно готовлю что-то? Прошу подсказать!
Скажу что это земля и небо. Попытаюсь пояснить свои мысли:
1) Современные Java IDE позволяют очень быстро перейти от production к unit-test и обратно, как правило это одна горячая клавиша у меня в NetBeans это ctrl+shift+'t'
2) В Java IDE тесты выполняются быстрее чем в C++. Потому что в С++ любая часть кода от которой зависит тестируемый production код должна быть скомпилирована. Насколько понял, а я в Java не большой знаток, там в Java не все компилируется, а только то что нужно для выполнения
Из чего выводы:
Чтобы прикручивать Unit-тесты в C++ проекты мне приходится дробить на более мелкие проекты, а это время! Т.е. время затрачиваемое на работу по TDD в C++ проектах значительно больше чем в Java-проектах.
Может быть неправильно готовлю что-то? Прошу подсказать!
Sign up to leave a comment.
Введение в программирование через поведение (BDD)