Чим відрізняються рамки BDD для Java? [зачинено]

Які плюси та мінуси кожної структури розвитку, спричиненої поведінкою (BDD) для Java?

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

Чи є сенс використовувати рамку BDD, якщо я вже використовую глузуючу бібліотеку (наприклад, Mockito )?

Я щойно закінчив зіставляти три рамки BDD для Java. Очевидно, що мої висновки мають досить коротку дату використання.

Злагода

• Дуже гнучка
• Дуже гарний результат звіту
• Приємна рамка плагінів
• Погано задокументовано. Мені довелося прочитати джерело, щоб зрозуміти це (на щастя, його надзвичайно хороша якість).
• Схоже, світильники, можливо, виявляться щільно пов'язаними з html.

EasyB

• Дуже неглибока крива навчання (навіть для нерозвинених розробників)
• Надзвичайно потужна інтеграція DBUnit
• Мабуть, немає підтримки параметрів (призводить до дуже розпливчастих історій або до дублювання тексту та коду (редагувати: насправді є, але документація на нього була дуже добре прихована.)
• Історія та Кодекс дуже щільно з'єднані (один і той же файл)
• Дуже базовий результат звіту
• Не вдалося плагіну IntelliJ працювати
• Неактивна спільнота (плагін Maven, здається, був зламаний протягом трьох місяців - не так багато прикладів коду для малювання)

JBehave

• Надзвичайно потужна та гнучка (наприклад, зменшення плит котла за допомогою композиції сюжетів як необхідних умов)
• Велика (якщо фрагментарна) документація та приклади
• Широка (якщо переважна) підтримка різних фреймворків та середовищ
• Відмінне відокремлення файлів історій від коду
• Схоже, є досить активне співтовариство та ще багато прикладів та обговорень цього в Інтернеті.
• Досить крута крива навчання (мені знадобилось у 3-4 рази довше, ніж Concordion / EasyB)

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

"плюси і мінуси" можуть бути різними для різних людей. Я зазвичай дивлюся на це

• діяльність , наприклад, нові ймовірні версії або останній випуск 2 роки.
• зрілості , наприклад, скільки часу це було, чи є підручники та, можливо, навіть книги. (Я не читаю цих книг, це лише знак прийняття.)
• підтримка інструментів , наприклад, чи є плагін Eclipse, підтримка мурашок тощо
• Розміри залежностей , мені не подобаються рамки, які поставляються зі своїм власним. наприклад, я хочу сам обрати свої глузуючі рамки.
• вид ліцензії , це важливо для мене через юридичні умови в компанії, в якій я працюю.
• сумісність із відповідними інструментами , наприклад, використовує він мову Gherkin чи ні.

І з якихось рамок я мав на це поглянути

• Інстинкт поганий : остання активність березня 2010 року, хороша : ліцензія ASF
• JDave погано : постачається з матрицями та макетами, добре : остання активність січень 2011 року, ліцензія ASF
• easyb bad : остання активність Жовтень 2010, не впевнений : він використовує Groovy. Це може бути нормально, але в моєму випадку це буде проблемою для прийняття.
• квасоля погана : лише одна версія 2007 року, це мертве
• bdoc погано : остання активність січня 2010 року, не впевнений : схоже, йде іншим шляхом, створюючи звіт з коду.
• спокінг поганий : можливо, трохи екстремальний, це повна рамка тестування, не тільки BDD, добре : дуже активно, дуже круто.
• jbehave , "мати" всіх BDD на Java, погано : дуже потужна = складна, несумісна ліцензія (для мене), поставляється майже з кожною тестовою бібліотекою та багато іншого, хорошого : заснована на RSpec і тому сумісна, плагіни eclipse, інтеграція Maven , дуже активна громада
• ginkgo4j , BDD-рамка для Java, що також базується на RSpec Ruby, але використовуючи лямбда-Java (замість анотацій), що дозволяє створювати високо контекстуальні, легко читаються тести. Простий. Дуже потужний. Ліцензія Apache 2 з відкритим кодом.

Щодо макетів: Вам також неодмінно потрібен глузливий каркас. Структури BDD просто допомагають вам писати характеристики, але для деяких тестів знадобляться макети або заглушки, особливо. коли ви проектуєте зверху вниз (від огляду до деталей).

Яка найкраща рамка BDD для використання з Java? Чому? Які плюси і мінуси кожної структури?

Ось цікавий посилання про Concordion vs. Cucumber та Java Acceptance Testing

Тут я знайшов пару з них, але я не впевнений, яку вибрати.

Дійсно, погляньте на згадане вище.

Чи є сенс використовувати рамку BDD, якщо я вже використовую глузуючу бібліотеку (наприклад, Mockito)?

Коротка відповідь: так, безумовно. Насправді, прийняття тестування за допомогою BDD фрейму та одиничне тестування в ізоляції з використанням макетних об'єктів настільки різні, що я насправді не ставлю питання. Тестування приймання - це тестування чорної скриньки, тести використовуються для перевірки того, що функція бізнесу працює і ідеально написана бізнес-аналітиком. Тести підрозділу в ізоляції з використанням макетів - це тестування білого поля, тести використовуються для перевірки того, чи працює підрозділ та написано розробниками. Обидва корисні, але вони мають абсолютно різні цілі. Іншими словами, використання Mockito взагалі не замінює рамки BDD, а також зворотне.

Спочатку я робив свій BDD з простого jUnit, але останнім часом я дивився на JDave, оскільки це майже 1: 1 на те, що я робив з jUnit. Він також працює поверх jUnit, тому він вже працює на Eclipse, а також його легко налаштувати для роботи на системах безперервної інтеграції, таких як Хадсон. Не можу насправді порівняти його з іншими, але мій досвід роботи з JDave був хорошим поки що.

О, і ніколи не дурна думка використовувати макети! Вони спеціально не пов'язані з TDD / BDD, їх мета - в цілому полегшити тягар тестування.

Нічого собі, я бачу тему гарячу, багато хороших відповідей ...

Іронія вбік, я нещодавно виявив BDD і вважав цю концепцію цікавою. Гей, це змушує писати і тести ... і технічні характеристики! Як не дивно, як може здатися, останнього також може бракувати в деяких проектах ... Або просто бракує точності, яку BDD змушує запровадити.

Стаття про поведінку, керовану розвитком, узагальнює концепцію та посилання на деякі добрі статті (наприклад, до тієї, яку написав Ендрю Гловер). Більше того, до теми цього потоку він дає досить вичерпний (я думаю) перелік фреймворків BDD, велика кількість з них призначена для Java.
Це не вирішує проблему вибору рамки, але принаймні полегшить пошук ...

Оскільки BDD значною мірою покладається на читабельність тестового коду, я вважаю, що хорошим критерієм вибору є перегляд швидких екскурсій / навчальних посібників і побачити, який з них здається більш відповідним вашому стилю. Іншими критеріями може бути той факт, що ви знайомі з інструментами для використання в рамках (тестування одиниць, глузування), використання з IDE тощо.

я намагався Cucumber-JVM (раніше розроблявся як Cuke4Duke). Він використовує DSL Gherkin для специфікації, зберігається як звичайний текст.

Його можна запустити як тест JUnit. Тож єдина проблема почати його використовувати - це змусити ділових людей чи менеджера продуктів читати / писати .features у джерелах.

Результати

Моя команда використовує JBehave деякий час . Для зберігання специфікацій використовується звичайний текстовий файл. Кожен крок (Дано, Коли, Тоді) виконується певним методом, який може витягувати параметри з кроку. Сценарії можуть бути відступними та добре відформатованими, що дуже допомагає, якщо клієнти хочуть їх перевірити.

Є і деякі проблеми. Ми перейшли на Java 6. Іноді деякі кроки сценарію ігноруються під час виконання. Це може спричинити чимало клопоту з'ясувати, де помилка.

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