Связь между BDD и TDD

Каково отношение BDD и TDD?

Из того, что я понял, BDD добавляет две основные вещи в TDD: тесты именования (обеспечить /должны) и приемочные тесты. Должен ли я следовать TDD во время разработки BDD? Если да, должны ли мои тесты TDD быть названы в том же стиле /должны быть?

27 голосов | спросил SiberianGuy 1 +04002011-10-01T17:28:23+04:00312011bEurope/MoscowSat, 01 Oct 2011 17:28:23 +0400 2011, 17:28:23

3 ответа


35

BDD добавляет цикл вокруг цикла TDD.

Итак, вы начинаете с поведения и позволяете этому управлять вашими испытаниями, а затем пусть тесты приводят к разработке. В идеале BDD управляется каким-то приемочным тестом, но это не на 100% необходимо. Пока вы определяете ожидаемое поведение, вы в порядке.

Итак, допустим, вы пишете страницу входа.

Начните с счастливого пути:

Given that I am on the login page
When I enter valid details
Then I should be logged into the site
And shown my default page

Этот синтаксис «данный-и-когда-и-тогда-и» является синонимом, характерным для разработки с учетом поведения. Одно из преимуществ этого заключается в том, что он может быть прочитан (и с обучением, написано) не-разработчиками, то есть ваши заинтересованные стороны могут просмотреть список поведенческих действий, которые вы определили для успешного завершения задачи, и посмотреть, соответствует их ожиданиям задолго до того, как вы выпустили неполный продукт.

Существует язык сценариев, известный как Gherkin, который очень похож на вышеизложенное и позволяет вам написать тестовый код за предложениями в этом поведении. Вы должны искать переводчика на основе Геркина для своей обычной структуры разработки. Это выходит за рамки этого ответа.

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

Итак, пришло время переключиться на цикл TDD, чтобы обеспечить эту функциональность.

Если вы пишете BDD или нет, ваши тесты должны быть названы общим синтаксисом. Одним из наиболее распространенных является синтаксис «should», который вы описали.

Напишите тест: ShouldAcceptValidDetails. Пройдите цикл Red-Green-Refactor, пока вы не будете довольны этим. Проходим ли мы сейчас к тесту поведения? Если нет, напишите еще один тест: ShouldRedirectToUserDefaultPage. Red-Green-Refactor, пока вы не будете счастливы. Промыть, промыть, повторить, пока вы не выполните критерии, установленные в поведении.

Затем мы переходим к следующему поведению.

Given that I am on the login page
When I enter an incorrect password
Then I should be returned to the login page
And shown the error "Incorrect Password"

Теперь вы не должны упускать это из-за своего более раннего поведения. На этом этапе вы должны пропустить этот тест. Поэтому опуститесь до своего цикла TDD.

И так далее, пока у вас не будет страницы.

Настоятельно рекомендуем книгу Rspec узнать больше о BDD и TDD, даже если вы не разработчик Ruby.

ответил pdr 1 +04002011-10-01T18:46:27+04:00312011bEurope/MoscowSat, 01 Oct 2011 18:46:27 +0400 2011, 18:46:27
4

Мое понимание:

  • BDD началась как ребрендинг TDD, чтобы сделать акцент на поведении более ясным.
  • Это дает более официальную поддержку (DSL и инструментарий) для фокусировки на поведении и исполняемых спецификациях.
  • BDD теперь можно рассматривать как надмножество TDD. Это увеличилось с течением времени, чтобы охватить больше требований, связанных с требованиями, но все же сторона процесса разработки является основной частью этого.

Итак, чтобы обратиться к TDD, выполните правую часть BDD. BDD начал с изменения языка TDD, чтобы сделать процесс прозрачным. Вводная статья Dan North о BDD объясняет, почему полезно сосредоточиться на поведении слов, а не на тестах - это помогает подтвердите, что вы не просто строите право программного обеспечения, вы также создаете правильное программное обеспечение. Это всегда было частью хорошего подхода TDD, но Дэн немного кодифицировал его в BDD.


Что я думаю, что BDD делает бит более явным, чем TDD, или, по крайней мере, формализует и предоставляет поддержку инструмента, это двухтактный /двойной цикл /масштабирование в режиме уменьшения /внешнего входа. Сначала вы описываете ожидаемое поведение функции (внешний цикл), а затем приближаетесь к внутреннему циклу для работы с низкоуровневыми спецификациями.

 Doubleloop TDD Из http://www.metesreau.com/ncraft-workshop/

Gherkin в сочетании с такими инструментами, как Cucumber и SpecFlow, обеспечивает способ записи этих спецификаций характеристик высокого уровня, а затем их связывание с кодом, который выполняет код приложения. Я бы сказал, что именно здесь BDD может «чувствовать себя» отличным от TDD, но он по-прежнему делает то же самое, только с некоторой дополнительной поддержкой инструмента и DSL. Несколько ближе к «традиционному» TDD используются такие инструменты, как rspec, nspec, spock. Это немного похоже на тот же процесс, что и в традиционном TDD, но с более ориентированным на поведение языком.

В BDD в действии от Джона Фергюсона Смарта (рекомендуется), он выступает за подход с двойной петлей, начиная с чего-то вроде jBehave на исполняемых спецификациях внешнего уровня, а затем переходит в инструмент, такой как Spock для низкоуровневых спецификаций.


BDD приближает концепцию тестирования к заинтересованным сторонам. Gherkin разработан, чтобы быть понятным для бизнеса, и идея «живой документации», т. Е. Автоматически создавала отчеты о ходе выполнения ваших исполняемых спецификаций, заключается в предоставлении обратной связи заинтересованным сторонам.

Другая часть BDD теперь, где она действительно становится чем-то, что включает TDD как часть более крупного процесса, - это требования к битам и кускам требований. Идеи, такие как Feature Injection, Impact Mapping и Real Options, являются частью этой стороны.

Для канонического ответа на это лучше всего

ответил ngm 26 42015vEurope/Moscow11bEurope/MoscowThu, 26 Nov 2015 18:13:52 +0300 2015, 18:13:52
2
  

Каково отношение BDD и TDD?

Это одно и то же.

  

Из того, что я понял, BDD добавляет две основные вещи в TDD: тесты именования (гарантируют /должны)

На самом деле это не что-то BDD «добавляет». Это просто другое соглашение, которое призвано облегчить обучение и понимание TDD.

Люди, создавшие BDD, обучали TDD, и они заметили, что самое сложное для понимания было то, что TDD не имеет абсолютно никакого отношения к тестированию. Когда ученики преодолели это препятствие, им стало намного легче. Но очень сложно отвлечься от размышлений о тестировании , когда слово «тест» (или родственная терминология, такое как «assert») появляется практически везде . Итак, они переключили несколько слов.

Но это только слова! Существует фактическая разница нет между TDD и BDD.

  

и приемочные испытания.

Приемочные тесты столь же важны как часть TDD, как и BDD. Опять же: нет разницы между TDD и BDD: TDD done right is BDD, BDD есть TDD сделан правильно.

ответил Jörg W Mittag 1 +04002011-10-01T18:40:00+04:00312011bEurope/MoscowSat, 01 Oct 2011 18:40:00 +0400 2011, 18:40:00

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132