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

Question

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

Answer 1

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

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

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

http://www.scalatest.org/quick_start

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

Specs 比 ScalaTest 有更多的匹配器，我认为这反射(reflect)了设计态度的不同。我实际上削减了我构建并考虑发布的匹配器语法的 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 中解决问题可能比在规范中更容易解决。

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

=== ，这意味着等于

> ，这意味着大于

< ，小于

>= , 大于或等于

<= ，小于或等于。

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

result should be <= 7

我希望你不需要跑到 API 文档来猜测 <=意味着。相比之下，运营商的规范要自由得多。这没什么错，但这是不同的。操作符可以使代码更简洁，但代价是当你发现诸如 ->- 之类的东西时，你可能必须运行到文档中。 , >> , | , |> , ! , 或 ^^^ (在 Specs 中都有特殊含义)在您同事的测试代码中。

另一个哲学上的区别是，当您需要共享夹具时，我确实尝试使在 ScalaTest 中使用函数式风格更容易一些，而默认情况下 Specs 延续了 setUp 的传统。和 tearDown由 JUnit 推广的方法，在这种方法中，您在每次测试之前重新分配变量。但是，如果您想以这种方式进行测试，在 ScalaTest 中也很容易。你只需要混入 BeforeAndAfter特质。

要更深入地了解 ScalaTest，您可以在此处观看我在 2009 Devoxx session 上发表的“使用 ScalaTest 获得更高”的演讲:

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