В чем разница между фреймворками BDD для Java? [закрыто]

Каковы плюсы и минусы каждой структуры разработки на основе поведения (BDD) для Java?

Вот , например, я нашел некоторые из них .

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

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

Concordion

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

EasyB

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

JBehave

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

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

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

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

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

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

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

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

Вот интересная ссылка о Concordion vs. Cucumber и приемочном тестировании на основе Java.

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

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

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

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

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

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

Вау, тема горячая, много хороших ответов ...

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

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

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

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

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

Полученные результаты

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

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

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