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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

BDD в целом

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

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

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

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

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

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

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

Минусы:

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

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