dima_tuzov
Дмитрий Тузов

Сижу читаю "BDD in action - John Ferguson". Надеюсь поможет... А то когда статью писал, был дзен, а теперь каша в голове...

(33) "Геркин - не значит "прокликивание" мышкой и приемочные тесты с высокой степенью детализации, хотя я догадываюсь, откуда у вас такие впечатления." - вот это кстати очень похоже на реальность. А откуда это утверждение? Ссылка на "авторитетный" источник есть?

(30) Спасибо за ссылку, сразу не нашел.

(23) Ок. Пример будет. Выложу отдельной статьей, как продолжение к реферату...

Коллеги, давайте договоримся. Те кто толк в BDD не видят, сюда не пишут. А кто изучил вопрос вдоль и поперек, помогите раскрыть тему и убрать "недосказанности" из статьи. Есть вещи о которых я не написал, или написал недостаточно для понимания сути - жду вопросы. Не надо писать типа - и что дальше? или - как то все криво... Давайте по существу - я попробовал вот это, у меня не получилось вот то...

(16) Критиковать BDD, да и вообще Agile-методы можно только попробовав их использовать на практике. Если у вас есть такая практика, поделитесь....

(11) Почему вы противопоставляете понятие формальности и обязательности? Понятное дело, что ТЗ будут требовать и вам придется его писать... Вам предлагается инструмент, который поможет вам это сделать корректно и в короткий срок.

(10) Реальные примеры приводят Алексей Лустин и Леонид Паутов (Ссылки в статье).

(12) Я понял, такое ощущение у большинства, кто раньше не сталкивался с BDD. Формулируйте вопросы, будем общаться.

Я воспринимаю ТЗ по ГОСТу, как формальность. Представьте, что на этапе постановки задачи, вы ведете переговоры с заказчиком и конспектируете это в виде Gherkin. Вам это будет удобнее, чем писать какую-то прозу с абзацами и пунктами. Появится дополнительная информация по заданию, вам такую нотацию будет легче исправить, добавить группу "И" в "Когда", исправить пару "И" в "Тогда"... это ваш инструмент, не обязательно ему обучать заказчика.
Заказчик требует от вас ТЗ, а вы получили все ответы на вопросы? Всем известно, сколько таких вопросов возникает уже в процессе программирования. Неожиданно поняли, что БП кривой.. Нельзя проводить этот документ не создав тот.. а вот тут вообще нужен был новый справочник... и тд...
Когда вы пишите на Gherkin, вы по сути уже начали программировать и очень много начинает всплывать. А если сразу задумаетесь о связи Gherkin с кодом (как это уже было описано), вы сможете реально оценить время, которое уйдет на кодинг. Что после этого стоит написать ТЗ по ГОСТу?