如何使用specs2对测试进行分组? [英] How to group tests using specs2?

问题描述

我已经习惯了JUnit，在JUnit中，仅通过在单个文件(类)中定义这些测试并用@Test对其进行注释，就可以对多个测试(通常与一个类相关)进行分组.然后，要运行其中的几个测试，请使用@Suite.SuiteClasses创建一个TestSuite，依此类推.

I'm used to JUnit, in JUnit it is possible to group several tests (usually related to a class) just by defining these tests in a single file (class) and annotating them with @Test. Then, to run several of these tests, a TestSuite is created with @Suite.SuiteClasses and so on.

在specs2中，可以将扩展某些Specification的两个级别的多个测试组合在一起.例如:

In specs2 it is possible to group several tests at two different levels extending some Specification. For example:

  "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中的文件，然后每个作为JUnit中的Suite，除了Suite被分为几个类，而Specification处于单个类(即文件)中，这往往会产生巨大的文件.

We can group several Specification of this type in a single file, and each one of them can pack several checks, each check would be like a @Test, each group like a file in JUnit and then each Specification as a Suite in JUnit, except a Suite is splitted into several classes and a Specification is in a single class (i.e. file), which tends to produce huge files.

所以问题有两个:

• 我应该把这些内容放在哪里，这取决于组织和可读性:一个Specification以及每个班级应该做的事情，即应该通过的检查.
• 如果将整个测试组分为几个文件，如何创建Suite，如果可能的话，将它们按分层方式进行分组，例如作为 Suites 用于ScalaTest.

• Where should I put the stuff as a matter of organization and readability: a Specification and the things that each class should do, i.e. the checks that it should pass.
• If the whole group of tests is split into several files, how can I create a Suite that groups them if possible in a hierarchical way, e.g. as Suites for ScalaTest.

顺便说一句:我使用Specs2是因为我认为它是标准的(默认情况下是原型，一个(非常简化的)小型(轶事)样本证实了这一[ 2 ])，但我正在考虑使用ScalaTest.通过数字判断( specs2 ， scalatest )，这可能是遵循Scala社区标准和习俗的最佳选择.我之所以这样说，是因为出于这些原因，诸如不可能，请使用ScalaTest"这样的答案是可以接受的.

BTW: I'm using Specs2 because I think it is the standard (was by default with the archetype, a (very reduced) small (and anecdotal) sample corroborates this [1, 2]), but I am considering to use ScalaTest. Judging by numbers (specs2, scalatest) that may be the best option to follow standards and customs of the Scala community. I mention this because an answer like "it's not possible, use ScalaTest" would be acceptable for these reasons.

推荐答案

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

In specs2 there is no concept of a hierarchical suite. A Specification is just a list of examples. Even when you group them with xxx should yyy, this just affects the way the examples are displayed in the console, with more or less indentation.

另一方面，可以使用 specs2 来组织规范:

On the other hand there are ways to organize specifications with specs2:

• 参考
• 标签

• references
• tags

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

You can create a hierarchy of specifications by creating a top-level specification referencing other ones:

// 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 参数

The child specifications can reference other specifications and so on. What's different from JUnit (and possibly from ScalaTest) is that your reference graph doesn't need to be a tree. When you execute a Specification with the all argument

sbt> test-only ParentSpec -- all

然后是ParentSpec的依赖项，因此低级别的依赖项先于高级的依赖项执行.而且任何循环都是中断的，因此您不会无限执行(或获得StackOverflowError).

then dependencies are followed from the ParentSpec so that the low-level dependencies are executed before the high-level ones. And any cycles are broken so that you won't be executing things infinitely (or get a StackOverflowError).

标签是对事物进行分类的一种非常方便的方法，因为给定的事物"不必仅属于一个类别.当时，这是 TestNG 带来的重大改进之一.在 specs2 中，您可以标记单个示例或整个规范，然后根据某些标签的包含/排除声明要运行的示例.例如

Tags are a very convenient way to classify things because a given "thing" doesn't need to belong to only one category. This was, at the time, one of the great improvements brought by TestNG. In specs2 you can tag single examples or whole specifications and then declare which examples you want to run based on the inclusion/exclusion of some tags. For example

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标签的示例

Then you can execute only the specifications with the functional tag but not with the examples having the io tag

sbt> test-only -- include functional exclude io

组织

使用参考和标签，您可能可以想象出几种将测试源切成薄片和切成小方块的方法:

Organization

Using references and tags you can probably imagine several ways to slice and dice your test source:

• 您可以使用参考来创建规范的主要分类法"
• 您可以使用标签创建跨领域"关注点，例如io，slow，database，scalacheck ...

• you can use references to create a main "taxonomy" of specifications
• you can use tags to create "cross-cutting" concerns like io, slow, database, scalacheck...

请注意，您还可以将以上所有内容混合使用，并在参考文献上加上标签，并在示例和参考文献中添加规范，等等.

Note that you can also mix all of the above and have tags on your references, specifications with both examples and references, and so on.

选择给定结构的标准是:

The criteria for choosing a given structure are:

• 代码库中的概念导航
• 不同套件的执行速度
• 更改后仅需要重新运行测试的某些方面
• 基础架构约束(并非所有事物都可以在任何环境中运行)

这篇关于如何使用specs2对测试进行分组?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！