Из этой истории я делаю вывод, что вы пишете код самостоятельно.
Обычно целью BDD является обеспечение диалога, особенно между бизнесом и разработчиками, чтобы команда могла быть уверена, что они достигли общего понимания. Нам также нравится включать тестеров, потому что они могут определить, когда мы пропустили сценарии.
Если вы делаете это самостоятельно, возьмите резиновую утку и объясните утке поведение вашего приложения. Приведите несколько примеров того, как это должно работать. Это будут ваши сценарии.
Для начала я бы предложил не автоматизировать эти сценарии. Вы можете записать их, если хотите. Помните, что бизнес-результаты, которыми вы поделились с уткой, находятся на подходящем уровне, чтобы сформулировать их. Теперь вы должны иметь представление о том, как работает приложение, и вы можете выполнить сценарии вручную. Мне нравится относиться ко всему, что еще не работает, как к ошибке . Я бы иногда начал с автоматизацией, но только тогда , когда я очень хорошо знаю , как работает система, я знаком с инструментами, а пользовательский интерфейс хорошо понимают. Даже тогда мне часто приходится немного переделывать, когда я пишу код.
На более низком уровне расскажите своей утке, как будет вести себя каждый класс. Приведите несколько примеров. Резиновые утки прекрасно понимают технический язык. Теперь у вас есть BDD на уровне юнитов, или юнит-тесты. Цикл красно-зеленого-рефактора происходит здесь. (Мне больше не нужно много заниматься рефакторингом, потому что я думаю об обязанностях моих классов, формулирую их на бизнес-ориентированном языке, и в любом случае это имеет тенденцию выпадать довольно красиво. Но я Я делаю это некоторое время. Это нормально, если вы делаете.)
Не рефакторинг это слишком много. Мы по-прежнему хотим получать отзывы о нашем коде, потому что всегда есть вещи, о которых мы не знаем, которых мы не знаем . Совершенство - твой враг здесь. Сделайте это достаточно хорошо, сделайте его читабельным, затем двигайтесь дальше. Если вам нужно сделать что-то совершенное, чтобы внести дальнейшие изменения, делайте это, когда вносите дополнительные изменения.
Если у вас есть возможность получить отзывы о ваших сценариях от заинтересованных сторон бизнеса, но они не находятся рядом с вами, вы можете отправить им сценарии сразу после того, как вы их написали, и до того, как автоматизировать их. Возможно, вы захотите отправить макет пользовательского интерфейса, чтобы они могли соотносить слова с действиями. Не слишком далеко впереди кодирования с этим. Работайте с предположением, что то, что вы уже сделали, неправильно , и вам нужно получить обратную связь, чтобы узнать, как это сделать.
Как последний совет, обычно не формулируйте истории с точки зрения пользователя (сценарии, да, но не истории). Это не пользовательские истории. Вероятно, следует читать что-то вроде:
In order to attract people to my website
As @thom
I want users to easily convert months and days to days.
В любом случае, вы ищете цель более высокого уровня. Это также поможет вам извлечь необходимые возможности. Удачи с этим, и извинения за очень длинный пост.