Спецификации и 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