Это может помочь думать о BDD в его самой легкой форме; как дискуссии вокруг конкретных сценариев.
У вас есть варианты использования. У вас есть свои требования. Теперь вы хотите убедиться, что вы действительно хорошо понимаете их. Итак, кто-то - может быть, разработчик, может быть, тестер - говорит: «Хорошо. Просто чтобы убедиться, что я понимаю ... учитывая, что мы начинаем с , когда пользователь делает , тогда должно произойти . не так ли? "
И тестер скажет: «Да, все верно».
Тогда UX или аналитик говорит: «Ну, это правильно, если <этот другой контекст не существует>».
При обсуждении сценариев время, затрачиваемое на то, чтобы у всех было общее понимание, резко сокращается. Обычно мы скрываем очевидные сценарии и фокусируемся на крайних случаях; на новых предметных терминах, понятиях, которые различаются между отделами, сложные взаимодействия с унаследованными системами.
Разработчики на самом деле не работают над тест-кейсами. Они работают исходя из требований и критериев приемлемости точно так же, как и всегда. Тестовые случаи просто становятся примером того, чего они могут ожидать; сценарии, в которых пользователи получают выгоду или передают ценность системы. Автоматизация этих тестовых случаев может быть полезна, поскольку усилия по тестированию увеличиваются примерно пропорционально размеру базы кода.
BDD лучше всего работает в проектах, где существует высокая неопределенность относительно требований или предметной области, и понимание людей сильно различается. Если ваш проект уже работает, то придерживайтесь его. Возможно, вы могли бы взглянуть, где находится самый большой разрыв между идеями и их реализацией, и если BDD поможет вам в этом пространстве, используйте его; в противном случае выберите что-то другое. В любом случае то, что вы делаете, очень похоже на процессы BDD.