В чем разница между средами модульного тестирования ScalaTest и Scala Specs?

Оба являются средами модульного тестирования для Scala, написанными на Scala, с поддержкой BDD (Behavior Driven Development). И спецификации, на которых построены, могут также включать фреймворк ScalaTest . Но что предлагает спецификации ScalaTest? Какие отличия?

Спецификации и ScalaTest - хорошие инструменты для довольных пользователей, но они отличаются по нескольким параметрам. Вы, вероятно, захотите выбрать один в качестве основного инструмента тестирования в Scala, но не нужно отказываться от другого, потому что вы можете использовать части обоих. FeatureSpecНапример, если вам нравится синтаксис ScalaTest и синтаксис Mockito спецификаций, вы можете поместить оба файла jar в свой путь к классам и использовать их одновременно. Здесь я попытаюсь зафиксировать основные различия в философии дизайна, которые я заметил между спецификациями и ScalaTest.

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

ScalaTest поддерживает BDD через его Spec, FeatureSpec, WordSpec, FlatSpec, и GivenWhenThenчерты, а также имеет черты , которые можно смешивать , чтобы получить хороший синтаксис Сличитель. Если вам нравится «следует», вы смешиваете ShouldMatchers. Если вам нравится «must», вы можете добавить его MustMatchers. Но если вам нравится BDD, но не нравится синтаксис сопоставления, вы можете просто использовать одну из черт ScalaTest Spec без добавления черты сопоставления. В Specs есть класс Specification, который вы расширяете, и вы должны использовать слово «must» в выражениях сопоставления. Существенная философская разница, которая здесь очевидна, заключается в том, что ScalaTest дает вам гораздо больше возможностей выбора. Чтобы упростить навигацию по этому выбору, я привожу здесь дерево решений:

http://www.scalatest.org/quick_start

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

В Specs больше сопоставлений, чем в ScalaTest, и я думаю, что это отражает разницу в подходе к дизайну. Я фактически вырезал, вероятно, 2/3 синтаксиса сопоставления, который я построил и рассмотрел для выпуска. Я добавлю больше сопоставлений в будущих выпусках, но хотел быть уверенным, что знаю, что пользователи действительно чего-то хотят, прежде чем я добавлю это. Однако средства сопоставления ScalaTest включают в себя синтаксис сопоставления динамических свойств, который устраняет некоторые из этих недостатков. Например, в спецификациях вы можете написать java.io.File:

file must beDirectory

Это вызовет isDirectoryи убедится, что это правда. В java.io.Filesнастоящее время в ScalaTest нет специальных сопоставителей , но в ScalaTest вы можете просто использовать динамическую проверку, подобную этой:

file must be a ('directory)

Каждый раз, когда вы передаете символ после be, он будет использовать отражение для поиска (в данном случае) названного метода или поля directoryили названного метода isDirectory. Есть также способ сделать это статичным, определив BePropertyMatcher(обычно требуется всего 2 или 3 строки кода). Так что в ScalaTest я стараюсь предоставить больше функциональности с меньшим количеством API.

Еще одна общая разница в подходе к дизайну между спецификациями и ScalaTest заключается в неявных преобразованиях. По умолчанию при использовании ScalaTest вы получаете только одно неявное преобразование, которое накладывает ===оператор на все. (Если вам нужно, вы можете «отключить» это неявное преобразование с помощью одной строчки кода. Единственная причина, по которой вам может понадобиться это сделать, - это если вы пытались протестировать что-то, имеющее свой собственный ===оператор, и получили конфликт. ) ScalaTest определяет множество других неявных преобразований, но чтобы использовать их, вам нужно явно «пригласить» их в свой код, добавив трейт или выполнив импорт. Когда вы расширяете классSpecificationв спецификациях, я думаю, по умолчанию вы получаете десятки неявных преобразований. Я не уверен, насколько это будет иметь значение на практике, но я полагаю, что люди захотят протестировать код, который использует их собственные имплициты, и иногда может возникать конфликт между имплицитами тестовой среды и производственным кодом. Когда это произойдет, я думаю, что будет проще обойти проблему в ScalaTest, чем в спецификациях.

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

• ===, что означает равно
• >, что означает больше, чем
• <, меньше, чем
• >=, больше или равно
• <=, меньше или равно.

Вот и все. Так что эти вещи очень похожи на то, что значат. Если вы видите в чужом коде:

result should be <= 7

Я надеюсь, что вам не нужно будет обращаться к документации API, чтобы понять, что это <=значит. Напротив, в спецификациях операторы гораздо свободнее. Ничего страшного в этом нет, но это разница. Операторы могут сделать код более кратким, но Компромисс это вы , возможно , придется работать с документацией , когда вы найдете такие вещи , как ->-, >>, |, |>, !, или ^^^(что все они имеют особое значение в Спекуляциями) в тестовом коде вашего коллеги.

Еще одно философское отличие состоит в том, что я пытаюсь сделать в ScalaTest немного проще использовать функциональный стиль, когда вам нужно поделиться фикстуром, тогда как Specs по умолчанию продолжают традицию setUpи tearDownподход, популяризированный JUnit, в котором вы переназначаете переменные. перед каждым тестом. Однако, если вы хотите протестировать таким образом, в ScalaTest это тоже очень просто. Вам просто нужно добавить BeforeAndAfterчерту.

Чтобы получить больше информации о ScalaTest, вы можете посмотреть презентацию «Станьте выше с помощью ScalaTest», которую я сделал на конференции Devoxx в 2009 году здесь:

http://parleys.com/play/514892260364bc17fc56bde3/chapter0/about

Основные различия (в основном с точки зрения спецификаций :-)):

• ScalaTest предоставляет больше "стилей тестирования", чем спецификаций (вы можете посетить каждый пункт на странице быстрого запуска, чтобы получить подробное представление о каждом стиле)

• ScalaTest и спецификации имеют другой набор сопоставителей. Вы можете сравнить их здесь для ScalaTest и здесь для спецификаций. С другой стороны, в спецификациях есть множество мелких функций, которые могут вам понравиться при написании спецификации: сопоставления xml, состав сопоставлений (простой способ повторно использовать сопоставители путем их преобразования), точные сбои, подробные различия для длинных строк, .. ,

• Mockito получил хорошую поддержку BDD в спецификациях: Mockito

• specs имеет DataTables, которые позволяют сгруппировать множество небольших примеров в своего рода таблицу (если вы можете использовать операторы в качестве разделителей таблиц)

• В спецификациях вы можете определить примеры, которые вложены как libidum и автоматически очищаются на каждом уровне.

Это, безусловно, очень частичное и предвзятое сравнение, и существует много других различий (а библиотеки все еще развиваются, ...).

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

Надеюсь, это поможет.

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

Поддержка IDE может быть другим моментом

Я пытался заставить Specs работать с Eclipse через JUnit, и я обнаружил, что официальное решение немного «взломано». Настройка спецификаций: http://code.google.com/p/specs/wiki/RunningSpecs#Run_your_specification_with_JUnit4_in_Eclipse

Интеграция ScalaTest (в том числе через JUnit) кажется менее хакерской. Тем не менее, у меня нет ни одного из них, чтобы работать так же хорошо, как JUnit и Java.

Настройка ScalaTest: http://groups.google.com/group/scalatest-users/web/running-scalatest-from-eclipse

Если одним из факторов принятия решения является время компиляции, масштабирование, похоже, работает лучше.

В настоящее время мы используем specs2 в нашем проекте, но страдаем от медленной компиляции в тестах. Я только что закончил POC по переходу на масштабируемую версию и увидел, что время компиляции сократилось примерно в 0,82 раза, просто переключив 2 фреймворка в некоторых из наших источников.