BDD в Scala - это должно быть некрасиво?

Question

Я использовал салат для питона в прошлом. Это простая структура BDD, где спецификации записываются во внешнем текстовом файле. Реализация использует регулярные выражения для идентификации каждого шага, доказывая возможность многократного использования кода для каждого предложения в спецификации.

Используя scala, либо с specs2, либо с scalatest, я вынужден писать спецификацию вместе с реализацией, делая невозможным повторное использование реализации в другом тесте (конечно, мы могли бы реализовать ее где-то в функции) и делая невозможным разделение реализация теста из самой спецификации (что я и делал, предоставляя клиентам приемочные тесты для проверки).

В заключение я поднимаю вопрос: учитывая важность проверки тестов клиентами, есть ли в BDD-средах для scala способ загрузить тесты из внешнего файла, вызывая исключение, если предложение в тесте еще не реализовано, и выполняя проверить нормально, если все предложения были реализованы?

Answer 1

Я только что обнаружил огуречный плагин для sbt. Тесты будут реализованы в test / scala, а спецификации будут храниться в test / resources в виде простых текстовых файлов. Я просто не уверен, насколько надежна библиотека и получит ли она поддержку в будущем.

Редактировать: выше это оболочка для следующего плагина, который прекрасно решает проблему и поддерживает Scala. https://github.com/cucumber/cucumber-jvm

Answer 2

Это все о компромиссах. Спецификации в стиле огурца великолепны, потому что это чистый текст, который легко редактируется и читается не кодерами.

Однако они также довольно жесткие в качестве спецификаций, потому что они налагают строгий формат, основанный на функциях и Given-When-Then. Например, в specs2 мы можем написать любой текст и аннотировать только те строки, которые предназначены для действий в системе или проверки. Недостатком является то, что текст становится аннотированным и что pending должен быть явно указан, чтобы указать, что еще не было реализовано. Кроме того, аннотация - это просто ссылка на некоторый код, живущий где-то, и вы, конечно, можете использовать обычные методы программирования для получения возможности повторного использования.

Кстати, ссылка выше - интересный пример компромисса: в этом файле первая спецификация "уродливее", но есть больше проверок во время компиляции, чем When шаг использует информацию из Given шаг или что у нас нет последовательности Then -> When шаги. Вторая спецификация более приятна, но также более подвержена ошибкам.

Тогда есть проблема поддержания регулярных выражений. Если существует четкое разделение между людьми, которые пишут функции, и людьми, которые их реализуют, то очень легко нарушить реализацию, даже если ничего существенного не изменится.

Наконец, возникает вопрос контроля версий. Кому принадлежит документ? Как мы можем быть уверены, что код синхронизирован со спецификацией? Кто изменяет спецификацию, когда это необходимо?

На сегодняшний день нет идеального решения. Мой собственный вывод заключается в том, что артефакты BDD должны быть в руках разработчиков и проверены другими заинтересованными сторонами, читая код напрямую, если он читается, или читая вывод html/pdf. И если артефакты BDD принадлежат разработчикам, они могли бы также использовать свои собственные инструменты, чтобы упростить их жизнь с проверкой (с использованием компилятора, когда это возможно) и обслуживанием (с использованием автоматического рефакторинга).

Answer 3

Вы сами сказали, что легко сделать реализацию, которую можно многократно использовать, обычными методами, которые Scala предоставляет для такого рода штук (методы, функции, признаки, классы, типы...), так что на самом деле проблем нет.

Если вы хотите предоставить версию без кода своему клиенту, вы все равно можете предоставить ему файлы кода, и если они не могут игнорировать небольшой синтаксис, вы, возможно, могли бы написать собственного репортера, записывающего весь текст в файл, возможно, даже отформатирован как HTML или что-то.

Другой вариант - использовать JBehave или любую другую платформу, основанную на JVM, они должны работать со Scala без проблем.

Answer 4

Основными критериями проектирования Эрика были устойчивость разработки исполняемой спецификации (посредством рефакторинга), а не первоначальное удобство из-за "красоты" простого текста.

см. http://etorreborre.github.io/specs2/

Особенности specs2:

1. Параллельное выполнение примеров по умолчанию
2. ScalaCheck свойства
3. Издевается с мокито
4. Таблицы данных
5. AutoExamples, где исходный код извлекается для описания примера
6. Богатая библиотека матчей
7. Легко создавать и создавать
8. Можно использовать с должен и должен
9. Возвращение "функциональных" результатов или выдача исключений
10. Повторно используется вне specs2 (например, в тестах JUnit)
11. Формы для написания фитнес-подобных спецификаций (с разметкой Markdown)
12. HTML-отчеты для создания документации для приемочных испытаний, для создания руководства пользователя
13. Фрагменты для документирования API с всегда актуальным кодом
14. Integration with sbt and JUnit tools (maven, IDEs,...)

Specs2 is quite impressive in both design and implementation. If you look closely you will see the DSL can be extended while you keep the typesafe-ty and strong command of domain code under development.

He who leaves aside the "is more ugly" argument and tries this seriously will find power. Checkout the structured forms and snippets