В чем разница между фреймворками модульного тестирования ScalaTest и Scala Specs?
-
19-09-2019 - |
Вопрос
Оба являются фреймворками модульного тестирования с поддержкой BDD (Behavior Driven Development) для Scala, написанными на Scala.И Технические характеристики построен на может также включать в себя Самый масштабируемый рамки.Но что предлагают спецификации, которых нет у ScalaTest?В чем заключаются различия?
Решение
Спецификации и ScalaTest - оба хороших инструмента для довольных пользователей, но они отличаются несколькими способами.Вероятно, вы захотите выбрать один из них в качестве основного инструмента тестирования в Scala, но вам не нужно отказываться от другого, потому что вы можете использовать части обоих.Если вам нравится Scalatest's FeatureSpec
синтаксис и синтаксис Mockito спецификаций, например, вы можете поместить оба файла jar в свой classpath и использовать оба одновременно.Здесь я попытаюсь описать основные различия в философии дизайна, которые я заметил между спецификациями и ScalaTest.
Вероятно, основное философское различие между инструментами заключается в том, что specs предназначен для разработки, основанной на поведении (BDD), тогда как ScalaTest является более общим.ScalaTest предоставляет характеристики, которые вы можете смешивать вместе, чтобы получить поведение, которое вы предпочитаете в своих тестовых классах, включая BDD, и вы также можете легко определить свое собственное поведение, если хотите чего-то другого.
ScalaTest поддерживает BDD через свой Spec
, FeatureSpec
, WordSpec
, FlatSpec
, и GivenWhenThen
черты, а также имеет черты, которые вы можете смешать, чтобы получить хороший синтаксис сопоставления.Если вам нравится "должен", вы добавляете ShouldMatchers.Если вам нравится "обязательно", вы смешиваете в MustMatchers
.Но если вам нравится BDD, но не нравится синтаксис matcher, вы можете просто использовать одну из особенностей ScalaTest, не добавляя ни одной черты matchers.Specs имеет класс спецификации, который вы расширяете, и вы должны использовать слово "must" в своих выражениях сопоставления.Большое философское различие, которое здесь очевидно, заключается в том, что ScalaTest предоставляет вам гораздо больше возможностей выбора.Чтобы упростить навигацию в этом пространстве выбора, я привожу здесь дерево решений:
http://www.scalatest.org/quick_start
Синтаксис сопоставления также отличается в ScalaTest и specs.В ScalaTest я попытался посмотреть, как далеко я могу зайти с помощью операторной нотации, и в итоге получил выражения matcher, которые читаются очень похоже на английские предложения, с пробелами между словами.Синтаксис спецификации matcher больше объединяет слова вместе с верблюжьим падежом.
В Specs больше сопоставлений, чем в ScalaTest, и это, я думаю, отражает разницу в подходе к дизайну.На самом деле я сократил, вероятно, 2/3 синтаксиса matcher, который я создал и рассматривал для выпуска.Я добавлю больше сопоставителей в будущих выпусках, но хотел быть уверенным, что пользователи действительно чего-то хотят, прежде чем я это добавлю.Однако сопоставители ScalaTest, включающие синтаксис сопоставления динамических свойств, частично компенсируют эту слабину.Например, в спецификациях вы можете написать на java.io.File
:
file must beDirectory
Это вызовет isDirectory
и убедитесь, что это правда.ScalaTest не имеет никаких специальных сопоставителей для java.io.Files
в настоящее время, но в ScalaTest, вы могли бы просто использовать динамическую проверку, подобную этой:
file must be a ('directory)
В любое время, когда вы передаете символ после be
, он будет использовать отражение для поиска (в данном случае) метода или поля с именем directory
или метод с именем isDirectory
.Существует также способ сделать это статичным, определив BePropertyMatcher
(для чего обычно требуется всего 2 или 3 строки кода).Итак, в основном в ScalaTest я стараюсь предоставить больше функциональности с меньшим количеством API.
Другое общее различие в отношении дизайна между спецификациями и ScalaTest
включает неявные преобразования.По умолчанию вы получаете только одно неявное преобразование при использовании ScalaTest, которое помещает ===
оператор во всем.(Если вам нужно, вы можете "отключить" это неявное преобразование одной строкой кода.Единственная причина, по которой вам нужно было бы это сделать, - это если бы вы пытались протестировать что-то, имеющее свои собственные ===
operator, и вы получаете конфликт.) ScalaTest определяет множество других неявных преобразований, но чтобы использовать их, вам нужно явно "пригласить" их в свой код, смешав в чертеже или выполнив импорт.Когда вы расширяете класс Specification
в спецификациях, я думаю, вы в значительной степени получаете десятки неявных преобразований по умолчанию.Я не уверен, насколько это будет иметь значение на практике, но я полагаю, что люди захотят протестировать код, который использует их собственные импликации, и иногда может возникнуть конфликт между импликациями тестовой платформы и производственным кодом.Когда это произойдет, я думаю, что, возможно, будет проще обойти проблему в ScalaTest, чем в спецификациях.
Еще одно различие в подходе к дизайну, которое я заметил, - это комфорт для операторов.Одна из моих целей состояла в том, чтобы любой программист, просматривающий чужой тестовый код, использующий ScalaTest, мог догадаться, в чем смысл, не заглядывая ничего в документацию ScalaTest.Я хотел, чтобы клиентский код ScalaTest был совершенно очевиден.Один из способов, которым проявилась эта цель, заключается в том, что ScalaTest очень консервативен в отношении операторов.Я определяю только пять операторов в ScalaTest:
===
, что означает , что равно>
, что означает больше , чем<
, меньше , чем>=
, больше или равно<=
, меньше или равно.
Вот и все.Так что эти вещи в значительной степени похожи на то, что означают.Если вы видите в чужом коде:
result should be <= 7
Я надеюсь, что вам не нужно будет обращаться к документации API, чтобы догадаться, что это <=
означает.Напротив, specs гораздо свободнее обращается с операторами.В этом нет ничего плохого, но это разница.Операторы могут сделать код более кратким, но компромисс заключается в том, что вам, возможно, придется обратиться к документации, когда вы обнаружите такие вещи, как ->-
, >>
, |
, |>
, !
, или ^^^
(которые все имеют особые значения в спецификациях) в тестовом коде вашего коллеги.
Еще одно философское отличие заключается в том, что я пытаюсь немного упростить в ScalaTest использование функционального стиля, когда вам нужно совместно использовать прибор, в то время как спецификации по умолчанию продолжают традицию setUp
и tearDown
подход, популяризированный JUnit, при котором вы переназначаете переменные перед каждым тестом.Однако, если вы хотите протестировать таким образом, это также очень просто в ScalaTest.Вам просто нужно смешать в BeforeAndAfter
черта характера.
Для получения более подробной информации о ScalaTest вы можете посмотреть презентацию "Get Higher with ScalaTest", которую я провел на конференции Devoxx 2009 года, здесь:
http://parleys.com/play/514892260364bc17fc56bde3/chapter0/about
Другие советы
Основные отличия заключаются в следующем (в основном с точки зрения спецификаций :-) ):
ScalaTest предоставляет больше "стилей тестирования", чем спецификаций (вы можете посетить каждый пункт списка на быстрый старт страница для получения подробного представления о каждом стиле)
ScalaTest и specs имеют разный набор сопоставителей.Вы можете сравнить их здесь для масштабирования и здесь для получения технических характеристик.С этой стороны, в спецификациях есть множество небольших функций, которые могут вам понравиться при написании вашей спецификации:сопоставители xml, композиция сопоставителей (простой способ повторного использования сопоставителей путем их преобразования), точные сбои, подробные различия для длинных строк, ...
Mockito получила хорошую поддержку BDD в спецификациях: Мокито
спецификации имеют Таблицы данных которые позволяют сгруппировать множество небольших примеров в своего рода таблицу (если вы можете использовать операторы в качестве разделителей таблицы)
В спецификациях вы можете определить примеры, которые вложены как libidum и автоматическая очистка на каждом уровне
Это, безусловно, очень пристрастное и предвзятое сравнение, и существует много других различий (и библиотеки все еще развиваются ...).
В конце концов, я думаю, что это действительно зависит от вашего стиля тестирования / указания.Если это просто (простая структура спецификации, настройки, ожидания, ...), то обе библиотеки будут выглядеть очень похожими.В противном случае у обоих есть свое представление о том, как все должно быть сделано.В качестве последнего примера этого вы можете взглянуть на тегирование:в Самый масштабируемый и в технические характеристики.
Я надеюсь, что это поможет.
Насколько я знаю, за исключением нескольких узкоспециализированных функций, все сводится к личным предпочтениям в зависимости от стиля.
Поддержка IDE может быть еще одним моментом
Я пытался заставить спецификации работать с Eclipse через JUnit, и я обнаружил, что официальное решение немного "халтурное".Настройка спецификаций: http://code.google.com/p/specs/wiki/RunningSpecs#Run_your_specification_with_JUnit4_in_Eclipse
Интеграция ScalaTest (также через JUnit) с кажется немного менее сложной.Тем не менее, у меня нет ни одного из них, который работал бы так же хорошо, как JUnit и Java.
Самая масштабируемая настройка: http://groups.google.com/group/scalatest-users/web/running-scalatest-from-eclipse
Если одним из решающих факторов является время компиляции, scalatest, похоже, работает лучше.
В настоящее время мы используем specs2 в нашем проекте, но страдаем от медленного времени компиляции в тестах.Я только что закончил POC по переходу на scalatest и увидел, что время компиляции сократилось примерно в 0,82 раза, просто переключив 2 фреймворка в некоторых наших источниках.