Чи можна BDD масштабувати для середніх та великих проектів?

На кожному веб-сайті, який ви читаєте про BDD (Behavior Driven Development), ви знайдете дуже простий приклад, який показує, наскільки очевидно і легко визначити свої вимоги. Але спроба втілити цей процес у великий продукт (не на прикладі калькулятора) показала мені, що речі можуть отримати (або вийдуть) досить складними і нечитабельними; особливо зміна запитів пізніше означає багато роботи, щоб виправити інтеграційні тести для цього.

Тож мені цікаво, чи дійсно варто BDD? Чи вирішує це проблема, якої інші методи не роблять!

Я думаю, що одним із найкращих ресурсів BDD є специфікація за книгою прикладів . Це багато розповідає про те, як організувати тести BDD і як їх слід записати, щоб вони не викликали стільки переробку, коли змінюються вимоги.

Якщо у ваших тестах щось стає складним або надто складним, то, ймовірно, ви робите щось не так. Так само і з BDD і TDD. Писати хороші тести важко, і на це потрібно кілька місяців.

Це може допомогти зрозуміти, що в центрі уваги BDD розмови . BDD - це дійсно інструмент аналізу, який дає змогу забезпечити тестування регресії як хороший побічний продукт.

Я використовував сценарії на різних рівнях у розмові; від визначення різних зацікавлених сторін, щоб побачити, чи може бути випуск добре сприйнятий, до розробки способу поведінки модуля чи класу .

Є кілька підказок та порад, які я можу запропонувати для полегшення цього.

Якщо ви ніколи цього не робили, це зміниться.

Все, що є новим для домену чи бізнесу, швидше за все, зміниться. Ви можете зрозуміти, що ви в цьому просторі, якщо ви розмовляєте за сценаріями, опитуєте їх , а бізнес каже: "О, я не впевнений". Це хороший знак, щоб перестати намагатися робити BDD і щось зробити, щоб отримати швидший зворотний зв'язок, щоб допомогти бізнесу розробити те, чого вони хочуть. Після того, як ідеї стабілізуються, сценарії можуть бути складені ретроспективно.

Усі проекти мають для них новий аспект, інакше ви їх не робите.

Якщо ви робили це раніше, це нудно.

Як і нові, різні аспекти, проекти зазвичай мають певний комодитизм аспекти до них , які аналогічні тим , які вже зроблені. Наприклад, якщо я виробляв новий мобільний телефон, йому все одно потрібно було б телефонувати. "Зробити телефонний дзвінок" - це настільки відомий сценарій, що нам не потрібно було б говорити через нього. Так само такі речі, як "вхід" або навіть "реєстрація користувача", нудні.

За можливості, використовуйте для них бібліотеки, і тоді вам не доведеться писати сценарії навколо них. Крім того , робити інші біти першим - має вже зареєстрований користувач і роботу, що він каротаж в протягом . Ці області навряд чи зміняться, тому ви, можливо, все-таки зможете піти з ручного тестування.

Якщо хтось робив це раніше, розмова через сценарії може допомогти.

Дещо між тим, де у нас є доменні вимоги, речі, які хтось досить добре розуміє , і де реальна невизначеність здебільшого стосується сфери, а не фактичної поведінки системи.

Розмова за сценаріями може допомогти команді розробників виявити поведінку, використати знання експерта та забезпечити захоплення відомої, цінної поведінки.

Це той біт, де BDD працює найкраще. Моя порада - написати найцікавіші сценарії у верхній частині файлу функцій (або вікі, якщо ви не автоматизуєте) та видалити будь-які сценарії, які дублюються або легко виводяться в результаті.

По можливості, використовуйте сценарії як приклади того, як працює програма . Наприклад, якщо ви хочете показати, як працює перевірка, покажіть кілька прикладів того, як програма допомагає користувачеві заповнити форму. Перевірте, чи перевіряється строга перевірка за допомогою тестування одиниць, що набагато простіше в обслуговуванні та швидшого запуску.

Подальше читання

Якщо вас це цікавить, я написав кілька речей, які можуть допомогти.

BDD у великому

Cynefin для розробок , який детальніше описується в цих трьох областях

Мої підручники-слайди , які всі приємні та помічені для вас, також охоплюють весь стек.

Ми створили досить складний проект ( складність домену ) минулої осені, і я, чесно можу сказати, вкладення передньої роботи в BDD врятувало проект. Я бачив сильну кореляцію між складністю домену та перевагами BDD.

Дозвольте мені одне вийти з дороги: тестування складних бізнес-правил важко. Питання в тому, чи хочете ви спробувати згадати всі шалені сценарії кожного разу, коли ви внесете зміни, чи хочете, щоб ця сітка безпеки повідомила вас про те, коли ви зламали специфікацію? Витратьте попередній час і опрацюйте всі сценарії, запишіть їх і, зрештою, напишіть усі тести для них.

А коли ви пізніше повернетесь, намагаючись зрозуміти речі, наявність цієї перевіряемої специфікації - це збереження життя.

BDD - це процес розробки, заснований на TDD (Test Driven Development) Ось деякі плюси і мінуси TDD, отримані з мого особистого досвіду:

• TDD, переконайтеся, що ваш обсяг чітко визначений. Таким чином ви спочатку розробляєте свої тестові справи. Тим самим задайте очікування для фрагмента коду, який ви повинні написати.
• TDD - це спосіб захисту вашого коду. Припустимо, ви пишете просту функцію, а потім пізніше додаєте деякі складні умови переключення в цю ж функцію. Завтра, якщо хтось інший захоче змінити цю функцію, він може звернутися до тестового випадку. Якщо він хоче змінити вашу функцію, значить, він мусить змінити тестовий випадок також (більшість випадків). Це дозволяє йому / їй зрозуміти, що за тим, що ви написали, було міркування.
• TDD дозволяє швидше розробити програмне забезпечення. Кожен з нас зіткнувся з цим питанням під час кодування. Почнемо з ідеї. І повільно втрачайте це. Ми в кінцевому підсумку ставимо небажані фрагменти коду для обробки деяких сценаріїв. У TDD ви встановлюєте очікування наперед. Тим самим ви обмежуєте себе не блукати занадто далеко від мети.
• TDD дозволяє ловити можливі помилки до виходу проекту в Інтернет. В основному це стосується якості написаних тестових випадків.

Мінуси:

• Спочатку TDD може бути дещо складним. Багато людей не розуміють концепцію розвитку тестового випадку.
• TDD, іноді може призвести до величезних зусиль у обслуговуванні. Це стосується небажаних або безглуздих тестових випадків.
• TDD слід приймати із щіпкою солі. Жоден розробник не любить витрачати час на тестовий випадок, написаний кимось іншим. Розшифровка значення тестової шафи іноді може спричинити великий головний біль.

Я працюю над проектом з більш ніж 900 000 рядків коду. І я все ще дотримуюся BDD. Одне головне, що вам потрібно врахувати, - це кількість можливих помилок, які ви можете викрити виключно через тестові випадки. Через кілька років ви будете клястись BDD!