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

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

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

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

http://www.scalatest.org/quick_start

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

В спецификациях больше сокетов, чем у ScalaTest, и я думаю, что это отражает разницу в дизайне. Я фактически сократил, вероятно, 2/3 синтаксиса-сопоставления, который я построил и рассмотрел для выпуска. Я добавлю больше матчи в будущих выпусках, но хочу быть уверенным, что знал, что пользователи действительно хотят чего-то, прежде чем я его добавлю. Тем не менее, в макетах ScalaTest используется динамический синтаксис сопоставления свойств, который принимает некоторые из этих слабых сторон. Например, в Specs вы можете написать на 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, чтобы угадать, что означает это <=. Напротив, спецификации намного свободнее с операторами. Ничего плохого в этом, но это разница. Операторы могут сделать код более кратким, но компромисс, возможно, придется запускать в документацию, когда вы найдете такие вещи, как ->-, >>, |, |>, ! или ^^^ (который все имеют специальные значения в Specs) в вашем тестовом коде коллеги.

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

Для более глубокого понимания ScalaTest вы можете посмотреть презентацию "Get Higher with ScalaTest", которую я дал на конференции Devoxx 2009 года:

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