Является ли BDD масштабируемым для средних и крупных проектов?

22

На каждом веб-сайте, который вы читаете о BDD (Behavior Driven Development), вы найдете очень простой хороший пример, показывающий, насколько очевидно и легко определить ваши требования. Но попытка реализовать этот процесс в большом продукте (не на примере калькулятора) показала мне, что вещи могут становиться (или будут) довольно сложными и нечитаемыми; особенно изменение запросов на более позднем этапе означает большую работу по исправлению интеграционных тестов для этого.

Поэтому мне интересно, действительно ли BDD того стоит? Это решает проблему, которую не делают другие методы!

DD
источник
Жаль, я думаю, что эта проблема довольно конструктивна, учитывая, что в последнее время BDD становится все более популярным.
ДД
1
Если кто-то с достаточным количеством представителей может предложить открыть снова, это были бы отличные ребята.
ДД
Я бы снова открыл, но вы уже приняли первый ответ ...
MattDavey
1
Я согласился, потому что это было закрыто, так что я знал, что больше ответов не было, но я действительно заинтересован в большем количестве отчетов об этом, пока я не приму это
DD
2
хорошо, отлично :) Я думаю, что вы также должны немного отредактировать вопрос. Я думаю, что ваш вопрос о масштабируемости BDD в больших проектах. «Действительно ли BDD настолько хорош» - это субъективно, «Хорошо ли масштабируется BDD для больших проектов» - это немного более объективно.
MattDavey

Ответы:

6

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

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

Петр Перак
источник
3
TDD не то же самое, тестирование предопределенного модуля никогда не может получить такой комплекс, если у вас нет слишком больших модулей, которые пахнут кодом, но интеграционные тесты должны проверять взаимодействие между более чем одним модулем, общую функциональность, это позволяет увеличить его сложность линейно по отношению к требованиям, тем не менее, вы не можете разбить его на более мелкие части, так как это не будет тестом на интеграцию, если это будет сделано.
DD
Вы можете прикрепить несколько сложных тестов BDD, и я смог увидеть, что можно сделать, чтобы сделать их проще.
Петр Перак
Это не так просто, те, что у меня здесь, не на английском языке, я должен был бы перевести их, если я найду требование, которое я могу легко перевести на английский, я могу приложить его, но все же код позади - это тоже проблема, которая будет слишком большой, чтобы прикрепить его в одном посте.
ДД
Почему это было отвергнуто? Я дал отличный ресурс, который поможет ОП решить его проблемы.
Петр Перак
это не я, я дам +1, чтобы компенсировать, но я могу сделать это только через 14 часов, поскольку я использовал все свои 30 голосов за сегодня.
ДД
5

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

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

Есть несколько советов и советов, которые я могу предложить, чтобы сделать это проще.

Если вы никогда не делали этого раньше, это изменится.

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

Все проекты имеют какой-то новый аспект, иначе вы бы их не делали.

Если вы сделали это раньше, это скучно.

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

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

Если кто-то делал это раньше, может помочь обсуждение сценариев.

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

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

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

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

дальнейшее чтение

Если вы заинтересованы в этом, вот несколько вещей, которые я написал, которые могут помочь.

BDD в целом

Cynefin для разработчиков , которые более подробно рассматриваются в этих трех областях

Мои учебные слайды , которые все приятно и аннотированы для вас, и охватывают весь стек тоже.

Lunivore
источник
Спасибо за этот информативный ответ, плохо читаю ссылки, которые вы прикрепили
DD
3

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

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

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

Адриан Шнайдер
источник
1

BDD - это процесс разработки, основанный на TDD (разработка через тестирование). Вот некоторые преимущества и недостатки TDD, основанные на моем личном опыте:

  • TDD, убедитесь, что ваша сфера четко определена. Таким образом, вы сначала разрабатываете свои тесты. Тем самым установите ожидание для части кода, которую вы должны написать.
  • TDD - это способ защиты вашего кода. Предположим, вы пишете простую функцию, а затем добавляете несколько сложных условий переключения в эту же функцию. Завтра, если кто-то еще захочет изменить эту функцию, он может обратиться к контрольному примеру. Если он хочет изменить вашу функцию, то ему также придется изменить контрольный пример (в большинстве случаев). Это позволяет ему понять, что за тем, что вы написали, была причина.
  • TDD позволяет быстрее разрабатывать программное обеспечение. Каждый из нас столкнулся бы с этой проблемой при кодировании. Мы начнем с идеи. И постепенно теряю это. В итоге мы добавили ненужные фрагменты кода для обработки некоторых сценариев. В TDD вы устанавливаете ожидания заранее. Тем самым вы ограничиваете себя в том, чтобы уходить слишком далеко от цели.
  • TDD позволяет выявлять возможные ошибки до того, как проект выходит в онлайн. Это в основном связано с качеством написанных тестовых случаев.

Минусы:

  • Во-первых, TDD может быть немного сложнее. Многие люди не понимают концепции разработки тест-кейсов.
  • TDD, иногда может привести к огромным усилиям по обслуживанию. Это имеет отношение к нежелательным или бессмысленным тестам.
  • TDD должен быть взят с щепоткой соли. Ни один разработчик не любит тратить время на тестовые сценарии, написанные кем-то другим. Расшифровка значения теста может иногда вызывать сильную головную боль.

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

Ricketyship
источник
2
Вам следует подробнее рассказать о различиях между BDD и TDD, а также о том, где появляется часть DDD.
Бенджамин Грюнбаум
1
@BenjaminGruenbaum В идеале, нет разницы между BDD и TDD. При правильном соблюдении BDD то же самое, что и TDD! Так что я не видел никакой причины вносить разницу как часть ответа. Спасибо за предложение, хотя!
Ricketyship
1
«TDD позволяет быстрее разрабатывать программное обеспечение». Были ли исследования, подтверждающие это? Просто любопытно. Я также хотел бы отметить, что ускорение не является линейным.
День
2
@AlexandreMartins Ха, абсолютно! Гораздо важнее признать, что у вас могут быть некачественные тесты и сценарии, чем притворяться, что они все хорошие IMO.
Лунивор
2
@Lunivore Да, это то, что беспокоит меня в случае BDD / TDD. Контрольные примеры должны быть сильными. К сожалению, в сообществе разработчиков существует мнение, что пока есть тестовые случаи, все в порядке! Однажды я видел тестовый пример, в котором строка вставлялась в таблицу с помощью оператора sql, и то же самое утверждается на следующем шаге! Разработчик пытался проверить функциональность оракула ?!
Ricketyship