ScalaTest 和 Scala Specs 单元测试框架有什么区别？

StackOverflow https://stackoverflow.com/questions/2220815

题

两者都是用 Scala 编写的具有 BDD（行为驱动开发）功能的 Scala 单元测试框架。和 眼镜 是建立在 还可能涉及到 Scala测试 框架。但是 Specs 提供了哪些 ScalaTest 没有提供的功能呢？有什么区别？

有帮助吗？

解决方案

Specs 和 ScalaTest 都是用户满意的好工具，但它们在几个方面有所不同。您可能会想选择一个作为 Scala 中的主要测试工具，但不必放弃另一个，因为您可以使用两者的一部分。如果你喜欢 ScalaTest FeatureSpec 语法和规范的 Mockito 语法，例如，您可以将两个 jar 文件放在类路径中并同时使用它们。在这里，我将尝试捕捉我注意到的规范和 ScalaTest 之间的主要设计理念差异。

这些工具之间的主要哲学差异可能是规范是为行为驱动开发（BDD）而设计的，而 ScalaTest 则更通用。ScalaTest 提供了一些特征，您可以将它们混合在一起以获得您在测试类中喜欢的行为，包括 BDD，如果您想要不同的东西，您还可以轻松定义自己的行为。

ScalaTest 通过其支持 BDD Spec, FeatureSpec, WordSpec, FlatSpec, ， 和 GivenWhenThen 特征，并且还具有可以混合以获得良好匹配器语法的特征。如果你喜欢“应该”，你可以混合ShouldMatchers。如果你喜欢“必须”，你就混进去 MustMatchers. 。但是，如果您喜欢 BDD 但不喜欢匹配器语法，您可以只使用 ScalaTest 的 Spec 特征之一，而无需混合匹配器特征。Specs 有一个您扩展的Specification 类，并且您必须在匹配器表达式中使用单词“must”。这里明显的一个重大的哲学差异是 ScalaTest 为您提供了更多的选择。为了使这个选择空间更容易导航，我在这里提供了一个决策树：

http://www.scalatest.org/quick_start

ScalaTest 和规范之间的匹配器语法也不同。在 ScalaTest 中，我尝试看看使用运算符表示法能走多远，最终得到的匹配器表达式读起来非常像英语句子，单词之间有空格。规格匹配器语法更多地使用驼峰式大小写将单词组合在一起。

Specs 比 ScalaTest 有更多的匹配器，我认为这反映了设计态度的差异。实际上，我削减了我构建并考虑发布的匹配器语法的大约 2/3。我将在未来的版本中添加更多匹配器，但想确保在添加之前我知道用户确实想要一些东西。然而，ScalaTest 的匹配器包含动态属性匹配器语法，弥补了部分不足。例如，在规格中，您可以写在 java.io.File:

file must beDirectory

这将调用 isDirectory 并确保它是真实的。ScalaTest 没有任何特殊的匹配器 java.io.Files 目前，但在 ScalaTest 中，您可以使用如下动态检查：

file must be a ('directory)

任何时候你在后面传递一个符号 be, ，它将使用反射来查找（在本例中）名为的方法或字段 directory 或名为的方法 isDirectory. 。还有一种方法可以使其静态，通过定义 BePropertyMatcher （通常只需要 2 或 3 行代码）。所以基本上在 ScalaTest 中我尝试用更少的 API 提供更多的功能。

规格和Scalatest之间的另一个一般设计态度差异涉及隐式转换。默认情况下，当您使用 ScalaTest 时，您只会获得一种隐式转换，即将 === 一切的操作员。（如果需要，您可以用一行代码“关闭”这种隐式转换。你需要这样做的唯一原因是如果你想测试一些有自己的东西 === ScalaTest 定义了许多其他隐式转换，但要使用它们，您需要通过混合特征或执行导入来显式“邀请”它们到您的代码中。当你延长课程时 Specification 在规范中，我认为默认情况下您几乎会获得数十个隐式转换。我不确定这在实践中有多重要，但我认为人们会想要测试使用自己的隐式代码的代码，有时测试框架的隐式代码和生产代码的隐式代码之间可能存在冲突。当这种情况发生时，我认为在 ScalaTest 中解决问题可能比规范更容易。

我注意到的设计态度的另一个差异是操作员的舒适度。我的目标之一是，任何查看其他人使用 ScalaTest 的测试代码的程序员都能够猜测其含义，而无需在 ScalaTest 文档中查找任何内容。我希望 ScalaTest 客户端代码非常明显。这一目标的体现之一是 ScalaTest 对于运算符非常保守。我在 ScalaTest 中只定义了五个运算符：

  • ===, ，这意味着等于
  • >, ，这意味着大于
  • <, ， 少于
  • >=, 大于或等于
  • <=, ，小于或等于。

就是这样。所以这些东西看起来很像意思。如果你在别人的代码中看到：

result should be <= 7

我希望您不需要跑到 API 文档来猜测那是什么 <= 方法。相比之下，运营商的规格要自由得多。这并没有什么问题，但还是有区别的。运算符可以使代码更加简洁，但代价是当您发现类似内容时，您可能必须运行文档 ->-, >>, |, |>, !, ， 或者 ^^^ （在规格中都有特殊含义）在您同事的测试代码中。

另一个哲学差异是，当您需要共享固定装置时，我确实尝试在 ScalaTest 中使用函数式风格稍微容易一些，而默认情况下，Specs 延续了 setUp 和 tearDown JUnit 流行的方法，在每次测试之前重新分配变量。但是如果你想以这种方式进行测试，在 ScalaTest 中也很容易。你只需要混合 BeforeAndAfter 特征。

要更深入地了解 ScalaTest，您可以观看我在 2009 年 Devoxx 会议上所做的“Get Better with ScalaTest”演示：

http://parleys.com/play/514892260364bc17fc56bde3/chapter0/about

其他提示

主要区别是（主要是从规格的角度来看:-)）：

  • ScalaTest 提供了比规范更多的“测试样式”（您可以访问 快速开始 页面以获取每种样式的详细视图）

  • ScalaTest 和规范有一组不同的匹配器。你可以比较它们 这里 对于 ScalaTest 和 这里 对于规格。在这方面，规范有许多您在编写规范时可能会喜欢的小功能：xml 匹配器、匹配器组合（通过转换匹配器来重用匹配器的简单方法）、精确失败、长字符串的详细差异，...

  • Mockito 在规范中得到了很好的 BDD 支持： 莫基托

  • 规格有 数据表 允许将许多小示例分组到某种表中（如果您可以忍受将运算符用作表分隔符）

  • 在规范中，您可以定义嵌套为 libidum 和 自动清理 在各个层面

这当然是一个非常片面和有偏见的比较，并且存在许多其他差异（并且库仍在不断发展......）。

归根结底，我认为这实际上取决于您的测试/指定风格。如果它很简单（简单的规范结构、设置、期望……），那么两个库将显得非常相似。否则，双方对于如何做事情都有自己的看法。作为最后一个例子，您可以看一下标记：在 Scala测试 并在 眼镜.

我希望这有帮助。

据我所知，除了一些高度专业化的功能外，这取决于风格的个人喜好。

IDE 支持可能是另一点

我一直在尝试通过 JUnit 让 Specs 与 Eclipse 一起工作，我发现官方的解决方案有点“hacky”。规格设置： http://code.google.com/p/specs/wiki/RunningSpecs#Run_your_specation_with_JUnit4_in_Eclipse

ScalaTest 的集成（也通过 JUnit）似乎不那么老套。尽管如此，我还没有让它们中的任何一个能够像 JUnit 和 Java 一样工作。

Scala 测试设置： http://groups.google.com/group/scalatest-users/web/running-scalatest-from-eclipse

如果一个决定因素是编译时间， scalatest 似乎表现更好。

我们目前在项目中使用specs2，但在测试中编译时间很慢。我刚刚完成了关于转向 scalatest 的 POC，发现仅通过切换一些源代码中的 2 个框架，编译时间就下降了约 0.82 倍。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top