Спецификации и ScalaTest являются хорошими инструментами для счастливых пользователей, но отличаются по нескольким параметрам. Возможно, вы захотите выбрать один в качестве основного инструмента тестирования в Scala, но вам не нужно отказываться от другого, потому что вы можете использовать части обоих. Если вам нравится, например, синтаксис ScalaTest FeatureSpec и синтаксис Mockito для спецификаций, вы можете поместить оба файла jar в путь к своим классам и использовать оба одновременно. Здесь я попытаюсь описать основные различия в философии дизайна, которые я заметил между спецификациями и ScalaTest.
Вероятно, основное философское различие между инструментами заключается в том, что спецификации предназначены для разработки на основе поведения (BDD), тогда как ScalaTest является более общим. ScalaTest предоставляет черты, которые вы можете смешивать вместе, чтобы получить поведение, которое вы предпочитаете в своих тестовых классах, включая BDD, и вы также можете легко определить свое собственное поведение, если вы хотите что-то другое.
ScalaTest поддерживает BDD через свои черты Spec, FeatureSpec, WordSpec, FlatSpec и GivenWhenThen, а также имеет черты, которые вы можете смешивать, чтобы получить хороший синтаксис соответствия. Если вам нравится «следует», вы смешиваете с «Должны». Если вам нравится «must», вы смешиваете MustMatchers. Но если вам нравится BDD, но не нравится синтаксис matcher, вы можете просто использовать одну из спецификаций ScalaTest Spec без смешения с чертой matchers. У Specs есть класс Specification, который вы расширяете, и вы должны использовать слово «must» в выражениях вашего сопоставителя. Большая философская разница, которая здесь очевидна, заключается в том, что ScalaTest предоставляет вам гораздо больше возможностей. Чтобы облегчить навигацию по этому выбору, я приведу здесь дерево решений:
http://www.scalatest.org/quick_start
Синтаксис соответствия также отличается в ScalaTest и спецификациях. В ScalaTest я пытался увидеть, как далеко я могу пойти с помощью операторной нотации, и в итоге получил выражения соответствия, которые очень похожи на английские предложения, с пробелами между словами. Синтаксис соответствия спецификаций объединяет слова вместе с регистром верблюда.
В спецификациях больше соответствий, чем в ScalaTest, и это, я думаю, отражает разницу в подходе к дизайну. На самом деле я сократил, вероятно, 2/3 синтаксиса соответствия, который я создал и рассматривал для выпуска. Я добавлю больше соответствий в будущих выпусках, но хотел быть уверен, что я знал, что пользователи действительно чего-то хотели, прежде чем я его добавил. Однако средства сопоставления 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, которое ставит оператор === для всего. (Если вам нужно, вы можете «отключить» это неявное преобразование одной строкой кода. Единственная причина, по которой вам нужно это сделать, - это если вы пытаетесь протестировать что-то, имеющее собственный оператор ===, и вы получаете конфликт.) ScalaTest определяет много других неявных преобразований, но чтобы использовать их, вам нужно явно «пригласить» их в свой код, смешивая в себе черту или выполняя импорт. Когда вы расширяете класс Specification в спецификациях, я думаю, вы по умолчанию получаете десятки неявных преобразований. Я не уверен, насколько это будет иметь значение на практике, но я полагаю, что люди захотят тестировать код, который использует свои собственные последствия, и иногда может возникнуть конфликт между последствиями инфраструктуры тестирования и производственным кодом. Когда это произойдет, я думаю, что в ScalaTest обойти проблему будет легче, чем спецификации.
Еще одно отличие в дизайне, которое я заметил, это комфорт с операторами. Одна из моих целей заключалась в том, чтобы любой программист, смотрящий на чужой тестовый код, использующий ScalaTest, мог догадаться, в чем смысл, ничего не изучая в документации ScalaTest. Я хотел, чтобы клиентский код ScalaTest был совершенно очевиден. Одним из проявлений этой цели является то, что ScalaTest очень консервативен в отношении операторов. Я определяю только пять операторов в ScalaTest:
===, что означает равно >, что означает больше, чем <, меньше >=, больше или равно <=, меньше или равно.
Вот и все. Так что эти вещи в значительной степени похожи на то, что означают. Если вы видите в чужом коде:
result should be <= 7
Я надеюсь, что вам не нужно будет обращаться к документации API, чтобы угадать, что означает <=. В отличие от спецификаций гораздо свободнее с операторами. В этом нет ничего плохого, но это разница. Операторы могут сделать код более кратким, но компромисс в том, что вам, возможно, придется обратиться к документации, когда вы найдете такие вещи, как ->-, >>, |, |>, ! или ^^^ (что у всех есть особые значения в спецификациях) в тестовом коде вашего коллеги.
Еще одно философское отличие состоит в том, что в ScalaTest я немного упрощаю использование функционального стиля, когда вам нужно совместно использовать осветитель, тогда как спецификации по умолчанию продолжают традицию подхода setUp и tearDown. популяризируется JUnit, в котором вы переделываете переменные перед каждым тестом. Однако, если вы хотите проверить это, в ScalaTest это тоже очень просто. Вам просто нужно смешать черту BeforeAndAfter.
Чтобы получить более подробную информацию о ScalaTest, вы можете посмотреть презентацию «Получите больше с ScalaTest», которую я дал на конференции Devoxx 2009 года здесь:
http://parleys.com/play/514892260364bc17fc56bde3/chapter0/about