Во-первых, некоторые определения;
TDD - это разработка, основанная на испытаниях, так как название предлагает тесты, которые мы производим, приводят поток нашего развития. Его обычно описывают в сочетании с циклом Red-Green-Refactor. Поэтому на практике мы пишем единичный тест, и он терпит неудачу, давая нам красное состояние, затем мы фиксируем код нашего приложения до тех пор, пока не пройдем тест, не дадим нам состояние Green и, наконец, реорганизуем наш код приложения и наш тестовый код, что у нас хороший дизайн. Хорошая TDD работает, сосредотачивая каждый тест на одном методе в классе, который мы хотим протестировать и вводить в заблуждение зависимые зависимости, поэтому мы тестируем минимально возможный объем кода, что приводит к тестовым наборам, где одна ошибка приводит к единичному сбою.
BDD - это разработка, основанная на поведении, где поведение является движущей силой нашего процесса проектирования. Когда вы следуете процессу BDD, вы взаимодействуете с людьми, чтобы выяснить, как ваше приложение должно функционировать, каковы его функции и какие примеры сценариев, в которых он должен работать. Фактически мы также можем рассмотреть BDD цикл, в котором мы собираем новый что приложение должно иметь, убедитесь, что приложение работает для всех сценариев, возможно, реорганизуйте наши тесты, чтобы они имели наибольший смысл и повторялись снова и снова. Для тестирования BDD часто требуется, чтобы многие классы сотрудничали в создании единой бизнес-функции, поэтому даже если ошибка вызывает только один сбой, у вас все еще есть большой код для отслеживания ответственного кода.
На данный момент вы можете увидеть, что BDD работает на более высоком уровне, чем TDD, на самом деле я видел внешний цикл BDD успешно используется для привода TDD внутренний цикл в более чем одной организации, т.е.
Define new business feature
---> Add scenario and test: BDD Red
| -> Add Unit test: TDD Red
| | Add application code: TDD Green
| -- Refactor code: TDD refactor
| Scenario passes: BDD green
--- Refactor feature and scenarios: BDD refactor
Feature complete
Gojko Adzic описывает это гораздо лучше в своей презентации TDD:Breaking the mould
Как это действительно полезно в веб-разработке? BDD очень полезен с точки зрения процесса, используемого для сбора требований и с помощью инструментов BDD, чтобы автоматически подтвердить, что ваша кодовая база имеет все функции, необходимые для бизнеса. Я нахожу, что BDD лучше всего работает с тестированием стиля интеграции с участием многих классов, вместо модульного тестирования, ориентированного на один метод.
Вы должны использовать BDD для создания своей прикладной логики, и вы можете использовать ее для проверки большей части вашего сайта. Я лично уклоняюсь от тестирования пользовательского интерфейса и вместо этого работаю в кодировке, используя такой язык, как «Когда пользователь ищет BDD», однако некоторые люди используют Selenium и записывают тесты, которые говорят о кликах и тестовых тестах «Когда пользователь вводит BDD в текстовом поле поиска и нажмите кнопку поиска ".
Стоит ли проводить время на BDD, а также TDD как занятый веб-разработчик в .net?
Надеюсь, к настоящему моменту вы сможете ответить на этот вопрос самостоятельно. Вам нужно решить, какую выгоду вы получите от внедрения BDD в ваш процесс. Ваши преимущества будут варьироваться в зависимости от таких факторов, как размер команды и инструменты, которые вы выбираете.
Отметьте, что вы просматриваете форму спецификации текстового формата инструмента BDD, пометив свой вопрос nBehave. Это позволяет вам иметь команду BA, которая работает над сценариями обычного текста и отправляет их обратно (хотя они не оставляют их для всех, вам нужен определенный технический вклад, чтобы согласовать сценарии). Другие формы инструментов, такие как mSpec, работают другим способом, используя C# для описания сценариев и создания простого текста в результате процесса сборки. Лично я использую SpecFlow, который имеет все преимущества nBehave, но его тесты можно запустить с помощью nUnit runner, resharper и вашего сервера сборки. Однако вы можете захотеть, чтобы ваши интеграционные тесты были отделены от ваших модульных тестов и, например, сообщали о разных уровнях охвата.
И наконец
Хотя эти инструменты часто разрабатываются специально для использования в BDD проектов, их можно рассматривать как специализированные формы оснастки, что поддерживает разработку тестами. Инструменты служат для добавления автоматизации в вездесущий язык, который является центральной темой BDD.
Это означает, что инструменты BDD работают аналогично существующим инструментам TDD и знают, как генерировать или понимать грамматику BDD из «Дано когда». Более подробно об этом я бы рекомендовал прочитать https://github.com/cucumber/cucumber/wiki/Gherkin.
Если вы хотите узнать больше о BDD как процесс, то Лиз Кео имеет много действительно хороший материал, начать здесь http://lizkeogh.com/behaviour-driven-development/
(И возгласы это намного больше, чем я думал, что будет, когда я начал)
спасибо, что это помогло :) – Neel
Спасибо, это приятно услышать :-) – AlSki