Как сгруппировать тесты с помощью spec2?

Я привык к JUnit, в JUnit можно сгруппировать несколько тестов (обычно связанных с классом), просто определив эти тесты в одном файле (классе) и аннотировав их с помощью @Test. Затем, чтобы запустить несколько таких тестов, создается TestSuite с @Suite.SuiteClasses и так далее.

В spec2 можно сгруппировать несколько тестов на двух разных уровнях, расширив некоторые Specification. Например:

  "Whatever" should {
    "do its job when possible" in {
      whatever(new Thing).work must beSome
    }
    "return none when not possible" in {
      whatever(null).work must beNone
    }
  }

Мы можем сгруппировать несколько Specification этого типа в один файл, и каждый из них может упаковать несколько проверок, каждая проверка будет как @Test, каждая группа как файл в JUnit, а затем каждая Specification как Suite в JUnit, за исключением Suite разбит на несколько классов, а Specification находится в одном классе (т.е. в файле), который имеет тенденцию создавать огромные файлы.

Таким образом, вопрос состоит из двух частей:

  • Куда я должен поместить материал с точки зрения организации и удобочитаемости: Specification и то, что должен делать каждый класс, то есть проверки, которые он должен пройти.
  • Если вся группа тестов разбита на несколько файлов, как я могу создать Suite, который группирует их, если это возможно, иерархическим образом, например. как Suites для ScalaTest.

Кстати: я использую Specs2, потому что я думаю, что это стандарт (был по умолчанию с архетипом, (очень уменьшенный) небольшой (и анекдотический) образец подтверждает это [1, 2]), но я рассматриваю использовать ScalaTest. Судя по цифрам (specs2, scalastest), что может быть лучшим вариантом для соблюдения стандартов и обычаев сообщества Scala. Я упоминаю об этом, потому что ответ типа «это невозможно, используйте ScalaTest» был бы приемлем по этим причинам.


unit-testing scala hierarchy specs2
person Trylks    schedule 19.03.2015    source источник

Ответы (1)


arrow_upward
11
arrow_downward

В specs2 нет понятия иерархического набора. Спецификация — это просто список примеров. Даже когда вы группируете их с помощью xxx should yyy, это просто влияет на то, как примеры отображаются в консоли, с большим или меньшим отступом.

С другой стороны, есть способы организовать спецификации с помощью specs2:

использованная литература

Вы можете создать иерархию спецификаций, создав спецификацию верхнего уровня, ссылающуюся на другие:

// code for specs2 3.x
class ParentSpec extends Specification { def is = s2"""
  These are all the important specifications about our domain
  ${"child1" ~ ChildSpec1}   
  ${"child2" ~ ChildSpec2}   
  """
}

Дочерние спецификации могут ссылаться на другие спецификации и так далее. Что отличается от JUnit (и, возможно, от ScalaTest), так это то, что ваш эталонный граф не обязательно должен быть деревом. При выполнении Спецификации с all аргумент

sbt> test-only ParentSpec -- all

затем зависимости следуют из ParentSpec, так что низкоуровневые зависимости выполняются перед высокоуровневыми. И любые циклы прерываются, так что вы не будете выполнять что-то бесконечно (или не получите StackOverflowError).

Теги

Теги — это очень удобный способ классификации вещей, потому что данная «вещь» не обязательно должна принадлежать только одной категории. В то время это было одним из больших улучшений, внесенных TestNG. В specs2 вы можете пометить отдельные примеры или целые спецификации, а затем объявить, какие примеры вы хотите запустить, основываясь на включении/исключении некоторых тегов. Например

class Spec1 extends mutable.Specification { section("functional")
   "simple test" >> ok

   tag("io")
   "a bit of IO" >> ok
}

class Spec2 extends mutable.Specification { section("functional")
   "another simple test" >> ok

   tag("io")
   "another bit of IO" >> ok
}

Тогда вы можете выполнять только спецификации с тегом functional, но не с примерами, имеющими тег io

sbt> test-only -- include functional exclude io

Организация

Используя ссылки и теги, вы, вероятно, можете представить себе несколько способов нарезки вашего тестового источника:

  • вы можете использовать ссылки для создания основной «таксономии» спецификаций
  • вы можете использовать теги для создания «сквозных» проблем, таких как io, slow, database, scalacheck...

Обратите внимание, что вы также можете смешивать все вышеперечисленное и иметь теги в своих ссылках, спецификации с примерами и ссылками и так далее.

Критериями выбора данной структуры являются:

  • навигация по концепциям в кодовой базе
  • скорость выполнения разных наборов
  • необходимость повторного запуска только некоторых аспектов ваших тестов после изменения
  • ограничения инфраструктуры (не все может работать в любой среде)
person Eric    schedule 20.03.2015
comment
Очень исчерпывающий ответ, спасибо. Я думаю, что есть два разных (синтаксических) стиля для определения тестов spec2, поэтому я также проверю документацию по другому. Это окончательно отвечает на вопросы. Спасибо. - person Trylks; 20.03.2015