Каковы различия между фреймворками BDD для Java?

Ответ 1

Я только что закончил сравнение трех фреймворков BDD для Java. Очевидно, что мои результаты имеют довольно короткий срок использования.

Concordion

• Очень гибкий
• Очень красивый вывод отчета
• Хорошая структура плагина
• Плохо документировано. Я должен был прочитать источник, чтобы понять его (к счастью, его чрезвычайно хорошее качество).
• Светильники, похоже, оказались тесно связанными с html.

EasyB

• Очень мелкая кривая обучения (даже для разработчиков Groovy разработчиков)
• Чрезвычайно мощная интеграция с DBUnit
• По-видимому, нет поддержки параметров (приводит к очень расплывчатым историям или дублированию текста и кода (редактирование: на самом деле есть, но документация для него была очень хорошо скрыта).
• История и код очень тесно связаны (тот же файл)
• Очень простой вывод отчета
• Не удалось заставить плагин IntelliJ работать
• Неактивное сообщество (плагин Maven, похоже, был разбит на три месяца - не много примеров кода для рисования)

JBehave

• Чрезвычайно мощный и гибкий (например, сокращение котельной плиты посредством составления рассказов в качестве предварительных условий)
• Обширная (если фрагментированная) документация и примеры
• Обширная (если подавляющая) поддержка различных фреймворков и сред
• Отличное разделение файлов истории из кода
• Похоже, у вас довольно активное сообщество и много примеров и обсуждение его в Интернете.
• Довольно крутая кривая обучения (мне приходилось в 3-4 раза дольше, чем Concordion/EasyB)

У меня не было возможности попробовать Cuke4Duke JDave, как мне бы хотелось, но, вероятно, в данный момент выйдет за JBehave.

Ответ 2

"За и против" могут быть разные вещи для разных людей. Я обычно смотрю на

• деятельность по развитию, например возможны ли новые выпуски или это последний выпуск 2 года.
• срок погашения, например сколько времени прошло, есть ли учебники и, возможно, даже книги. (Я не читаю эти книги, это просто знак усыновления.)
• поддержка инструмента, например есть ли подключаемый модуль Eclipse, поддержка Ant и т.д.
• размер зависимостей, мне не нравятся фреймворки, которые идут со всем своим. например Я хочу сам выбрать мою насмешливую основу.
• вид лицензии, это важно для меня из-за юридических условий в компании, в которой я работаю.
• совместимость со связанными инструментами, например Использует ли он язык корнишона или нет.

И из некоторых рамок я взглянул на

• Инстинкт плохой: последняя активность в марте 2010 года, хороший: лицензия ASF
• JDave bad: поставляется со спичками и издевательствами, good: последняя активность январь 2011, лицензия ASF
• easyb bad: последняя активность, октябрь 2010 г., не уверен: используется Groovy. Это может быть хорошо, но будет проблемой для усыновления в моем случае.
• Beanspec плохо: только одна версия в 2007 году, это мертвый
• bdoc bad: последнее действие в январе 2010 года, не уверен: похоже, что вы идете другим путем, создавая отчет из кода.
• спок плохо: может быть, немного экстремально, это полная среда тестирования, не только BDD, хорошо: очень активно, очень круто.
• jbehave, "мать" всех BDD в Java, плохая: очень мощная = сложная, несовместимая лицензия (для меня), поставляется практически с каждой библиотекой тестов и многим другим, хорошо: основано на RSpec и, следовательно, совместимо, плагины Eclipse, интеграция Maven, очень активное сообщество
• ginkgo4j, инфраструктура BDD для Java, также основанная на Ruby RSpec, но использующая лямбда-код Java (вместо аннотаций), позволяющий создавать тесты с высокой степенью контекста и высокой читаемостью. Просто. Очень могущественный. Лицензия Apache 2 с открытым исходным кодом.

Что касается насмешек: вам определенно нужны рамки для насмешек. Фреймворки BDD просто помогают вам в написании спецификаций, но некоторые тесты будут нуждаться в макетах или заглушках, особенно. когда вы разрабатываете сверху вниз (от обзора до деталей).

Ответ 3

Какая лучшая структура BDD для использования с Java? Зачем? Каковы преимущества и недостатки каждой структуры?

Вот интересная ссылка о Конкордион против огурца и тест на прием на основе Java

Я нашел пару из них здесь, но я не уверен, какой из них выбрать.

Действительно, посмотрите на упомянутый выше.

Имеет ли смысл использовать BDD-фреймворк, если я уже использую насмешливую библиотеку (например, Mockito)?

Короткий ответ: да, определенно. Фактически, приемочные испытания с использованием BDD-структуры и модульного тестирования изолированно с использованием макетных объектов настолько различны, что я действительно не задаю вопрос. Приемочное тестирование - тестирование черного ящика, тесты используются для проверки функционирования бизнес-функции и идеально написаны бизнес-аналитиком. Единичные тесты в изоляции с использованием mocks - это тестирование белого ящика, тесты используются для проверки работоспособности устройства и написания его разработчиками. Оба полезны, но они имеют совершенно разные цели. Другими словами, использование Mockito не заменяет структуру BDD вообще, и инверсия также верна.

Ответ 4

Я изначально сделал свой BDD с простым jUnit, но в последнее время я смотрел JDave, потому что он почти 1:1 к тому, что я делал с jUnit. Он также работает поверх jUnit, поэтому он уже работает на Eclipse, а также легко настраивается для работы с системами непрерывной интеграции, такими как Hudson. Невозможно сравнить это с другими, но мой опыт работы с JDave был до сих пор хорош.

О, и это никогда не глупая идея использовать насмешки! Они специально не привязаны к TDD/BDD, их цель - облегчить бремя тестирования в целом.

Ответ 5

Ничего себе, я вижу, что тема горячая, много хороших ответов...

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

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

Поскольку BDD в значительной степени зависит от читаемости тестового кода, я полагаю, что хорошим критерием выбора является просмотр быстрых туров/учебников и просмотр того, какой из них кажется более подходящим для вашего стиля. Другими критериями могут быть те инструменты, которые вы знакомы (unit test, mocking), использование с IDE и т.д.

Ответ 6

Я попробовал Cucumber-JVM (ранее разработанный как Cuke4Duke). Он использует Gherkin DSL для спецификации, хранится в виде простого текста.

Его можно запустить как тест JUnit. Поэтому единственной проблемой для начала его использования является заставить деловых людей или менеджера по продукту читать/писать .features в источниках.

Результаты

Ответ 7

Моя команда уже давно использует JBehave. Он использует текстовые файлы для хранения спецификаций. Каждый шаг (Given, When, Then) затем выполняется определенным методом, который может извлекать параметры с шага. Сценарии могут быть отступом и хорошо отформатированы, что очень помогает, если клиенты хотят их проверить.

Есть и некоторые проблемы. Мы перешли на Java 6. Иногда некоторые сценарии игнорируются во время выполнения. Это может вызвать массу проблем, когда выясняется, где ошибка.

Ответ 8

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