Я привык к 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» был бы приемлем по этим причинам.