Разработка, ориентированная на поведение, связана с проектированием или анализом?

Question

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

То, как я сейчас это вижу, таково:

1) анализ:BDD

От википедия

Результатом объектно-ориентированного анализа является описание того, что система функционально должна выполнять, в форме концептуальной модели.

Итак, после BDD у нас есть требования (истории и сценарии).Но я не уверен насчет концептуальной части модели.

2) дизайн:например, с помощью таких инструментов, как дизайн, основанный на резонансе, с использованием CRC-карт

3) код:кодирование дизайна, необязательно использование тестирования (например, то, что они говорят о том, что TDD сделано неправильно, что я также нахожу полезным)

Ошибаюсь ли я в том, как я это вижу?В данный момент мне трудно разглядеть лес сквозь деревья.

Answer 1

Короче говоря, это связано с анализом .

BDD предназначен для «разработки, основанной на приемочных тестах»; - т. е. для того, чтобы знать, ведет ли тестируемая система так, как ожидается для конкретного сценария пользовательской истории.

Когда я работал с Jbehave, мы использовали его на уровне пользовательских историй и все еще делали «обычный». TDD для обработки взаимодействий между отдельными объектами и между подсистемами.

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

В сценарии BDD указано , что должна сделать система для пользовательского рассказа , а не как это делает.

Answer 2

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

Таким образом, BDD не может быть о дизайне, BDD о тестировании функций / историй / сценариев, BDD ближе к анализу.

Answer 3

BDD - разработка, ориентированная на поведение

Поведение = .. в контексте .. Разработка - ... в строительстве ...

Развитие в этом случае указывает мне, что анализ был выполнен, и каждый реализует что-то, что находится в контексте определенного поведения.

поэтому, чтобы ответить на вопрос, я верю, что это в дизайне .

Answer 4

Я думаю, что архитектура POV BDD будет о дизайне. Мне нужно спроектировать приложение, которое может что-то сделать, чтобы потом было использовано при приемочном тестировании. Итак, из высокоуровневого дизайна я хочу убедиться, что я проектирую для различных требований к поведению, чтобы я не переусердствовал и ограничил дублирование.

Это помогает гарантировать, что нам, возможно, не потребуется перепроектировать, поскольку у пользователя есть больше времени, чтобы подумать о том, что он на самом деле хочет увидеть, как будет работать приложение.

Answer 5

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

Таким образом, BDD поддерживает анализ при создании тестов: вы должны описать поведение, требуемое в форме тестов или примеров. Он поддерживает проектирование при запуске тестов: ваши проектные решения не допускают случайного нарушения требуемого поведения и могут руководствоваться анализом. Но это не делает никакого анализа или дизайна для вас; ты все еще должен думать. Это способ убедиться, что на этапах анализа и проектирования вы не противоречите себе.

Answer 6

BDD и TDD в еще большей степени имеют очень неудачное название, потому что оно на самом деле не охватывает то, для чего они используются.

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

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

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

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

Потому что из того, что я понял из вашего вопроса, следует, что вы заранее создаете большой дизайн, а затем пытаетесь его закодировать.Это не сработает с BDD, потому что, удовлетворяя ваши истории, которые вы должны писать по частям, вы автоматически получаете свой код и архитектуру.Это называется эмерджентным проектированием, поэтому здесь нет большого этапа планирования.

В SCRUM или подобной системе wise это работает действительно хорошо, потому что бизнес уделяет приоритетное внимание вашим историям.Вы начинаете сверху и пишете спецификацию / пример для нее, затем пытаетесь выполнить пример, повторяя это до тех пор, пока не завершите этот элемент невыполненной работы, а затем берете следующий и начинаете все сначала.

Я надеюсь, что это ответ на ваш вопрос..если нет, вам нужно будет немного уточнить, потому что это тема braod.Короче говоря, BDD - это чисто инструмент разработчика, не для архитекторов, бакалавров...Тестировщики могут использовать инструменты BDD, но я надеюсь, что это не единственный инструмент, который они используют для тестирования приложения.