如何使用 specs2 对测试进行分组？

Question

我习惯了 JUnit，在 JUnit 中，只需在单个文件（类）中定义这些测试并用 @Test 注释它们，就可以将多个测试（通常与一个类相关）分组。然后，为了运行其中的几个测试，使用@Suite.SuiteClasses 创建一个TestSuite，依此类推。

在 specs2 中，可以在扩展 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 中的文件，然后每个@987654333 @ 在 JUnit 中作为 Suite，除了 Suite 被拆分为多个类，Specification 在单个类（即文件）中，这往往会产生巨大的文件。

所以问题有两个方面：

• 为了组织和可读性，我应该把这些东西放在哪里：Specification 以及每个类应该做的事情，即它应该通过的检查。
• 如果整个测试组被分成几个文件，我如何创建一个Suite，如果可能的话以分层方式对它们进行分组，例如作为 ScalaTest 的 Suites。

顺便说一句：我使用 Specs2 是因为我认为它是标准的（默认情况下是原型，一个（非常减少的）小（和轶事）样本证实了这一点 [1,2]），但是我正在考虑使用 ScalaTest。从数字（specs2、scalatest）来看，这可能是遵循 Scala 社区标准和习俗的最佳选择。我之所以提到这一点，是因为出于这些原因，像“不可能，使用 ScalaTest”这样的答案是可以接受的。

Answer 1

在 specs2 中没有分层套件的概念。规范只是示例列表。即使您将它们与xxx should yyy 分组，这也只会影响示例在控制台中的显示方式，或多或少缩进。

另一方面，有一些方法可以用 specs2 来组织规范：

• references
• tags

参考文献

您可以通过创建引用其他规范的顶级规范来创建规范层次结构：

// 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...

请注意，您也可以将以上所有内容混合在一起，并在您的参考文献上加上标签、带有示例和参考文献的规范等等。

选择给定结构的标准是：

• 代码库中的概念导航
• 不同套件的执行速度
• 在更改后仅重新运行测试的某些方面的必要性
• 基础设施限制（并非一切都可以在任何环境中运行）