З історії я роблю висновок, що ви кодуєте самостійно.
Зазвичай мета BDD полягає в тому, щоб дозволити розмови, особливо між бізнесом та розробниками, щоб команда могла бути впевнена, що вони дійшли спільного взаєморозуміння. Ми також хочемо включити тестери, оскільки вони можуть помітити, коли ми пропустили сценарії.
Якщо ви робите це самостійно, візьміть гумову качку та поясніть поведінку вашої заявки качці. Наведіть кілька прикладів, як це має працювати. Це будуть ваші сценарії.
Для початку я б запропонував не автоматизувати ці сценарії. Ви можете записати їх, якщо хочете. Пам’ятайте, що результати бізнесу, якими ви поділилися з качкою, приблизно на правильному рівні, щоб їх сформулювати. Тепер у вас має бути уявлення про те, як поводиться додаток, і ви можете прогоняти сценарії вручну. Мені подобається ставитися до всього, що ще не працює, як до помилки . Я б іноді почав з автоматизацією, але тільки тоді , коли я дуже добре знаю , як працює система, я знайомий з інструментами, а призначений для користувача інтерфейс добре розуміють. Навіть тоді мені часто доводиться переробляти це, коли я писав код.
На нижчому рівні розкажіть своїй качці, як поводиться кожен клас. Наведіть кілька прикладів. Гумові качки цілком здатні зрозуміти технічну мову. Тепер у вас є BDD-рівень на рівні одиниці, який також називається тестовими одиницями. Тут відбувається цикл червоно-зеленого рефактора. (Мені більше не потрібно більше рефакторировать, тому що я думаю про обов'язки своїх класів, формулюючи це мовою, орієнтованою на бізнес, і все одно вона випадає досить красиво. Але я я займаюся цим деякий час. Це нормально, якщо ви робите.)
Не переробляйте це занадто сильно. Ми все ще хочемо отримати зворотний зв'язок щодо нашого коду, тому що завжди є речі, про які ми не знаємо, що не знаємо . Вдосконалення - це ваш ворог тут. Зробіть його досить хорошим, зробіть його читабельним, а потім рухайтеся далі. Якщо вам потрібно зробити щось ідеальне, щоб внести подальші зміни, зробіть це, коли внесете подальші зміни.
Якщо у вас є можливість отримати відгук про свої сценарії від зацікавлених сторін бізнесу, але вони не сидіти з вами, ви можете надсилати сценарії до них, як тільки ви написали тоді, і перед тим, як автоматизувати їх. Ви також можете надіслати макет інтерфейсу користувача, щоб вони могли співвідносити слова з діями. Не надто далеко випереджаючи кодування цього. Працюйте з припущенням, що те, що ви вже зробили, є неправильним , і вам потрібно отримати зворотній зв'язок, щоб дізнатися, як це зробити.
В якості останньої підказки, як правило, не фразуйте історії з точки зору користувача (сценарії, так, але не історії). Вони не користувацькі історії. Напевно, слід прочитати щось на зразок:
In order to attract people to my website
As @thom
I want users to easily convert months and days to days.
Все одно є якась мета вищого рівня. Це також допоможе вам намалювати необхідні можливості. Удачі в цьому і вибачення за позадовгий пост.