Які первинні відмінності між TDD та BDD? [зачинено]

Програма, керована тестовими темпами, в останні кілька років викликала гнів у спільноті .NET. Нещодавно я почув бурчання в спільноті ALT.NET про BDD. Що це? Чим він відрізняється від TDD?

Я розумію, що BDD стосується більше специфікації, ніж тестування . Він пов'язаний з дизайном, керованим доменом (ви не любите ці * DD-акроніми?).

Це пов'язано з певним способом написання історій користувача, включаючи тести високого рівня. Приклад Тома десять Тія :

Story: User logging in
  As a user
  I want to login with my details
  So that I can get access to the site

Scenario: User uses wrong password

  Given a username 'jdoe'
  And a password 'letmein'

  When the user logs in with username and password

  Then the login form should be shown again

(У своїй статті Том продовжує безпосередньо виконувати цю тестову специфікацію в Ruby.)

Папою БДД є Дан Норт . Ви знайдете чудове вступ у його статті " Представлення BDD" .

У цьому відео ви знайдете порівняння BDD і TDD . Також думка про BDD як "TDD зробив правильно" Джеремі Д. Міллер

Оновлення 25 березня 2013 року

Відео вгорі деякий час відсутнє. Ось нещодавній проект Llewellyn Falco, BDD vs TDD (пояснено) . Я вважаю його пояснення зрозумілим і суттєвим.

Для мене головна відмінність BDD від TDD - це фокус і формулювання. І слова важливі для передачі ваших намірів.

TDD спрямовує увагу на тестування. А оскільки в «старому світі водоспадів» тести приходять після впровадження, то такий спосіб мислення призводить до неправильного розуміння та поведінки.

BDD спрямовує увагу на поведінку та специфікацію, і тому розум водоспаду відволікається. Тож BDD легше розуміти як практику проектування, а не як практику тестування.

Здається, існує два типи BDD.

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

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

Існує також група BDD, яка може бути вам корисною:

http://groups.google.com/group/behaviordrivendevelopment/

Test-Driven Development - це перша методика розробки програмного забезпечення, що означає, що вона вимагає написання тестового коду, перш ніж записати фактичний код, який буде перевірений. Слова Кента Бека:

Стиль тут полягає в тому, щоб написати кілька рядків коду, потім тест, який повинен запуститися, а ще краще, написати тест, який не запуститься, а потім написати код, який змусить його запустити.

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

Тож TDD - це технічна методологія низького рівня, яку програмісти використовують для створення чистого коду, який працює.

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

Як бачите, такі питання вимагають співпраці між технологією та бізнесом. Бізнес-зацікавлені сторони та експерти з питань домену часто можуть повідомити інженерам про те, який тип тестів здається їм корисним, але лише у тому випадку, якщо тести є тестами високого рівня, які стосуються важливих аспектів бізнесу. BDD називає такі бізнес-тести "прикладами", як у "скажіть мені приклад того, як ця функція повинна вести себе правильно", і зберігає слово "тест" для низьких рівнів технічних перевірок, таких як перевірка даних або тестування інтеграції API. Важлива частина полягає в тому, що, хоча тести можуть створювати тільки програмісти та тестери, приклади можуть бути зібрані та проаналізовані всією командою з доставки - дизайнерами, аналітиками тощо.

У реченні одне з найкращих визначень BDD, яке я знайшов дотепер, - це те, що BDD - це "бесіди з експертами по домену та використання прикладів для отримання спільного розуміння бажаної поведінки та виявлення невідомих". Частина відкриття дуже важлива. Оскільки команда з доставки збирає все більше прикладів, вони все більше і більше починають розуміти домен бізнесу і тим самим зменшують свою невпевненість щодо деяких аспектів товару, з якими вони мають мати справу. Із зменшенням невизначеності збільшується креативність та самостійність команди з доставки. Наприклад, тепер вони можуть почати наводити власні приклади, які бізнес-користувачі не вважали можливими через відсутність технічних знань.

Зараз спілкування з експертами з бізнесу та домену звучить чудово, але всі ми знаємо, як це часто закінчується на практиці. Я розпочав свою подорож із технологій як програміст. Як програмістів нас навчають писати код - алгоритми, шаблони дизайну, абстракції. Або, якщо ви дизайнер, вас вчать проектувати—Організуйте інформацію та створіть прекрасні інтерфейси. Але коли ми отримуємо робочі місця початкового рівня, наші роботодавці очікують, що ми «доставимо цінність для клієнтів». І серед цих клієнтів може бути, наприклад ... банк. Але я майже нічого не можу знати про банківську діяльність, окрім як ефективно зменшити баланс мого рахунку. Тож мені доведеться якось перекласти те, що від мене очікується, у код ... Я мав би побудувати міст між банківською діяльністю та моїми технічними знаннями, якщо хочу отримати будь-яку цінність. BDD допомагає мені побудувати такий міст на стійкому фундаменті постійної комунікації між командою з доставки та експертами з домену.

Вчи більше

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

Якщо ви зацікавлені у покупці "Написання чудових технічних характеристик", ви можете заощадити 39% за допомогою промо-коду 39nicieja2 :)

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

BDD також використовується як інструмент зв’язку. Метою є написання виконуваних технічних характеристик, які можуть бути зрозумілі експертам домену.

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

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

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

У статті у Вікіпедії є пояснення:

Поведінковий розвиток

Не практикую BDD сам.

Розглянемо основною перевагою TDD - дизайн. Його слід назвати Тестово керований дизайн. BDD - це підмножина TDD, називаємо її поведінковою конструкцією.

Тепер розглянемо популярну реалізацію TDD - Unit Testing. Одиниці тестування одиниць - це, як правило, один біт логіки, який є найменшою одиницею роботи, яку ви можете зробити.

Коли ви об'єднаєте ці Одиниці у функціональний спосіб, щоб описати бажану поведінку на машинах, вам потрібно зрозуміти поведінку, яку ви описуєте до машини. Дизайн, керований поведінкою, зосереджується на тому, щоб перевірити розуміння виконавцями принципів використання / вимог використання / що б там не було та перевірено реалізацію кожної функції. BDD та TDD взагалі служать важливою метою інформування дизайну та другою метою перевірки правильності виконання, особливо коли вона змінюється. BDD, виконане правильно, включає бізнес та dev (і qa), тоді як тестування одиниць (можливо, неправильно розглядається як TDD, а не одного типу TDD), як правило, проводиться у розробці силосу.

Додам, що тести на BDD служать життєвими вимогами.

BDD значною мірою TDD зроблено правильно. Однак, BDD пропонує додаткову цінність. Ось посилання на це:

BDD - це більше, ніж "TDD зроблено правильно"

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

Різниця між тестовою розробкою (TDD) і розвиненою поведінкою (BDD)

• BDD зосереджується на поведінковому аспекті системи, а не на
  аспекті впровадження системи, на яку зосереджується TDD.

• BDD дає чіткіше розуміння того, що система повинна робити
  з точки зору розробника та замовника. TDD лише
  дає розробнику розуміння того, що повинна робити система.

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

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

Ось короткий знімок:

• TDD - це лише процес тестування коду перед його написанням!

• DDD - це процес інформування про Домен перед кожним циклом торкання коду!

• BDD - це реалізація TDD, яка привносить деякі аспекти DDD!