Поведение, основанное на поведении, - это дизайн или анализ?

Question

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

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

1) анализ: БДД

из Википедии

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

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

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

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

Я ошибаюсь, как я это вижу? У меня проблемы с тем, чтобы увидеть лес сквозь деревья.

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Так что, чтобы ответить на вопрос, я верю, что в Дизайн .

Answer 3

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

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

Answer 4

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

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

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

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

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

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

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

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

Answer 5

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

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

Answer 6

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

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