在specs2中,可以在扩展某些规范的两个不同级别上对几个测试进行分组.例如:
"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 } }
我们可以将这种类型的几个规范组合在一个文件中,每个都可以打包几个检查,每个检查就像一个@Test,每个组像JUnit中的一个文件,然后每个规则作为JUnit中的一个套件,除了套件被分成几个类,而规范是在一个类(即文件)中,这往往会产生巨大的文件.
所以问题有两个:
>我应该把这些东西放在组织和可读性的问题上:规范和每个类应该做的事情,即它应该通过的检查.
>如果将整组测试分成多个文件,我该如何创建一个套件,如果可能的话,以分层方式对它们进行分组,例如:作为ScalaTest的Suites
.
BTW:我正在使用Specs2因为我认为它是标准(默认情况下是原型,一个(非常简化的)小(和轶事)样本证实了这个[1,2]),但我正在考虑使用ScalaTest.从数字(specs2,scalatest)来看,这可能是遵循Scala社区标准和习俗的最佳选择.我之所以提到这一点是因为出于这些原因,“不可能使用ScalaTest”这样的答案是可以接受的.
解决方法
> 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 }
然后,您只能使用功能标记执行规范,而不能使用具有io标记的示例执行
sbt> test-only -- include functional exclude io
组织
>您可以使用引用来创建规范的主要“分类法”
>您可以使用标签来创建“横切”问题,如io,slow,database,scalacheck ……
请注意,您还可以混合使用上述所有内容并在引用上添加标记,包含示例和引用的规范,等等.
选择给定结构的标准是:
>围绕代码库中的概念进行导航>不同套房的执行速度>在更改后仅重新运行测试的某些方面的必要性>基础设施限制(并非一切都可以在任何环境中运行)