Могут ли фреймворки xUnit и BDD работать вместе? - PullRequest
3 голосов
/ 23 мая 2011

Некоторые из прочитанных мной ресурсов относятся к BDD как к ответу «Плохой TDD».

  • Спецификация поведения против проверки. Нет неуместной близости между тестами и реализацией
  • Использование вездесущего / общего языка между тестировщиками развития бизнеса
  • Терминология подчеркивает «поведение» над «тестированием». Итак, данные, когда, контекст, сценарий, примеры и наборы тестов, приспособления и случаи.
  • Текущие характеристики

Не уверен, что пропустил больше преимуществ ... Пожалуйста, введите.

Учитывая, что большинство пользователей (может быть, местное явление) «сотрудничают» в создании / разработке / уточнении спецификаций, но не заинтересованы в редактировании / просмотре / исполнении / ведении автоматизированные версии (конечно, они ожидают, что программное обеспечение выполнит все спецификации):

Есть ли какой-то аспект xUnit (например, NUnit), который мешает ему быть хорошим инструментом для BDD?

  • Написание с точки зрения спецификаций - это навык, не зависящий от инструмента.
  • То же самое для вездесущего языка. Нужно лишь приложить усилия, чтобы вытащить его
  • Обратите внимание на вышеупомянутое ограничение. Предположим, я использую стиль именования тестов xUnit, который соответствует стилю BDD Given-When-Then.
  • Я получаю / создаю инструмент, который использует вышеупомянутое соглашение об именах для создания аналогичных «живых документов» из файлов результатов теста.

Может кто-нибудь пометить «Здесь будут драконы» на моей настроенной карте BDD ...

1 Ответ

2 голосов
/ 01 июня 2011

Вот вам и драконы.

  1. Автоматизация графического интерфейса остается сложной, независимо от того, на каком языке вы это делаете.
  2. Трудно сформулировать код на основеDSL в терминах, понятных бизнесу.
  3. Для написания DSL требуется немного времени.

Однако:

  1. Выполнение автоматизации вкод имеет тенденцию обеспечивать более быструю обратную связь, когда что-то идет не так, и его легче отлаживать.Также проще включить xUnit в вашу сборку.
  2. Проще поддерживать DSL на основе кода.
  3. Требуется гораздо больше времени, чтобы понять, как использовать, скажем, JBehave или Cucumber, чемэто действительно для написания DSL.

Как примечание, «реакция на плохой TDD», вероятно, относится к ранним временам BDD, когда мы делали это на уровне класса, а не в системе или приложенииlevel.

Я предлагаю примеры сценариев и поведения на уровне блока , написанных с использованием NUnit и DSL или Moq в C #.Работает для меня.Не используйте инструменты на естественном языке, если нет явной выгоды.Я внёс большой вклад в один из них, поэтому чувствую себя уполномоченным давать эту рекомендацию без ущерба.

Хотелось бы дать вам больше +1 за то, что вы указали разницу между созданием / разработкой / уточнением и редактированием / просмотром/ выполнения / сохранение!

...