Некоторые из прочитанных мной ресурсов относятся к BDD как к ответу «Плохой TDD».
- Спецификация поведения против проверки. Нет неуместной близости между тестами и реализацией
- Использование вездесущего / общего языка между тестировщиками развития бизнеса
- Терминология подчеркивает «поведение» над «тестированием». Итак, данные, когда, контекст, сценарий, примеры и наборы тестов, приспособления и случаи.
- Текущие характеристики
Не уверен, что пропустил больше преимуществ ... Пожалуйста, введите.
Учитывая, что большинство пользователей (может быть, местное явление) «сотрудничают» в создании / разработке / уточнении спецификаций, но не заинтересованы в редактировании / просмотре / исполнении / ведении автоматизированные версии (конечно, они ожидают, что программное обеспечение выполнит все спецификации):
Есть ли какой-то аспект xUnit (например, NUnit), который мешает ему быть хорошим инструментом для BDD?
- Написание с точки зрения спецификаций - это навык, не зависящий от инструмента.
- То же самое для вездесущего языка. Нужно лишь приложить усилия, чтобы вытащить его
- Обратите внимание на вышеупомянутое ограничение. Предположим, я использую стиль именования тестов xUnit, который соответствует стилю BDD Given-When-Then.
- Я получаю / создаю инструмент, который использует вышеупомянутое соглашение об именах для создания аналогичных «живых документов» из файлов результатов теста.
Может кто-нибудь пометить «Здесь будут драконы» на моей настроенной карте BDD ...