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

What’s the difference between ScalaTest and Scala Specs unit test frameworks?

提问by Alex

Both are BDD (Behavior Driven Development) capable unit test frameworks for Scala written in Scala. And Specsis built uponmay also involve the ScalaTestframework. But what does Specs offer ScalaTest doesn't? What are the differences?

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

回答by Bill Venners

Specs and ScalaTest are both good tools with happy users, but they differ in several ways. You will probably want to pick one as your main testing tool in Scala, but need not give up the other because you can use pieces of both. If you like ScalaTest's FeatureSpecsyntax and specs' Mockito syntax, for example, you can put both jar files in your classpath and use both at the same time. Here I'll try and capture the main design philosophy differences I've noticed between specs and ScalaTest.

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

Probably the main philosophical difference between the tools is that specs is designed for Behavior-Driven Development (BDD), whereas ScalaTest is more general. ScalaTest provides traits that you can mix together to get the behavior you prefer in your test classes, including BDD, and you can also easily define your own behavior if you want something different.

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

ScalaTest supports BDD through its Spec, FeatureSpec, WordSpec, FlatSpec, and GivenWhenThentraits, and also has traits that you can mix in to get a nice matcher syntax. If you like "should", you mix in ShouldMatchers. If you like "must", you mix in MustMatchers. But if you like BDD but don't like matcher syntax, you can just use one of ScalaTest's Spec traits without mixing in a matchers trait. Specs has a Specification class that you extend, and you must use the word "must" in your matcher expressions. A big philosophical difference that is evident here is that ScalaTest gives you a lot more choices. To make this space of choice easier to navigate, I provide a decision tree here:

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

http://www.scalatest.org/quick_start

http://www.scalatest.org/quick_start

The matcher syntax is also different between ScalaTest and specs. In ScalaTest I tried to see how far I could go with operator notation, and ended up with matcher expressions that read very much like English sentences, with spaces between the words. Specs matcher syntax runs words together more with camel case.

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

Specs has more matchers than ScalaTest, and that I think reflects a difference in design attitude. I actually cut probably 2/3 of the matcher syntax I built and considered for release. I will add more matchers in future releases, but wanted to be sure I knew users actually wanted something before I added it. However ScalaTest's matchers includes a dynamic property matcher syntax takes up some of that slack. For example in Specs you can write on a java.io.File:

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

file must beDirectory

This will invoke the isDirectoryand make sure it is true. ScalaTest does not have any special matchers for java.io.Filescurrently, but in ScalaTest, you could just use a dynamic check like this:

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

file must be a ('directory)

Anytime you pass a symbol in after be, it will use reflection to look for (in this case) a method or field named directoryor a method named isDirectory. There's also a way to make this static, by defining a BePropertyMatcher(which requires only 2 or 3 lines of code usually). So basically in ScalaTest I try to provide more functionality with less API.

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

Another general design attitude difference between specs and ScalaTest involves implicit conversions. By default you get only one implicit conversion when you use ScalaTest, which is the one that puts the ===operator on everything. (If you need to, you can "turn off" this implicit conversion with one line of code. The only reason you would need to do that is if you were trying to test something that has its own ===operator, and you get a conflict.) ScalaTest defines many other implicit conversions, but to use them you need to explicitly "invite" them into your code by mixing in a trait or doing an import. When you extend class Specificationin specs I think you pretty much get dozens of implicit conversions by default. I'm not sure how much that will matter in practice, but I figure people will want to test code that uses their own implicits, and sometimes there may be a conflict between the test framework's implicits and those of the production code. When that happens I think it may be easier to work around the problem in ScalaTest than specs.

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

Another difference in design attitude that I've noticed is comfort with operators. One goal I had was that any programmer looking at someone else's test code that uses ScalaTest would be able to guess what the meaning was without looking anything up in the ScalaTest documentation. I wanted ScalaTest client code to be drop dead obvious. One way that goal manifested itself is that ScalaTest is very conservative about operators. I only define five operators in ScalaTest:

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

• ===, which means equals
• >, which means greater than
• <, less than
• >=, greater than or equal
• <=, less than or equal.

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

That's it. So these things pretty much look like what mean. If you see in someone else's code:

而已。所以这些东西看起来很像什么意思。如果你在别人的代码中看到：

result should be <= 7

My hope is that you won't need to run to the API documentation to guess what that <=means. By contrast, specs is much freer with operators. Nothing wrong with that, but it is a difference. Operators can make code more concise, but the tradeoff is you may have to run to the documentation when you find things like ->-, >>, |, |>, !, or ^^^(which all have special meanings in Specs) in your colleague's test code.

我希望您不需要跑到 API 文档来猜测这<=意味着什么。相比之下，运营商的规范要自由得多。这没有什么错，但这是不同的。运营商可以使代码更简洁，但代价是你可能需要运行的文件，当你找到的东西一样 ->-，>>，|，|>，!，或^^^（这都在规格特殊的含义）在你同事的测试代码。

One other philosophical difference is that I do try and make it just slightly easier in ScalaTest to use a functional style when you need to share a fixture, whereas Specs by default continues the tradition of the setUpand tearDownapproach popularized by JUnit, in which you reassign vars before each test. However if you want to test that way, it is also very easy in ScalaTest. You just need to mix in the BeforeAndAftertrait.

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

For more insight into ScalaTest, you can watch the "Get Higher with ScalaTest" presentation I gave at the 2009 Devoxx conference here:

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

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

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

回答by Eric

The main differences are (mostly from a specs point of view :-) ):

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

• ScalaTest provides more "testing styles" than specs (you can visit each bullet point on the quick startpage to get a detailed view on each style)

• ScalaTest and specs have a different set of matchers. You can compare them herefor ScalaTest and herefor specs. On that side of things, specs has a lot of small features that you may like when writing your specification: xml matchers, matchers composition (an easy way to reuse matchers by transforming them), precise failures, detailed differences for long strings, ...

• Mockito has been given a nice BDD support in specs: Mockito

• specs has DataTableswhich allow to group a lot of small example in a sort of table (if you can stand operators being used as the table delimiters)

• In specs, you can define examples which are nested as libidum and automatically cleaned-upat every level

• ScalaTest 提供了比规范更多的“测试样式”（您可以访问快速入门页面上的每个项目符号点以获得每种样式的详细视图）

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

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

• specs 有DataTables，它允许将许多小示例分组在一种表格中（如果您能忍受将运算符用作表格分隔符）

• 在规范中，您可以定义嵌套为 libidum 并在每个级别自动清理的示例

This is certainly a very partial and biased comparison and many other differences exist (and the libraries are still evolving, ...).

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

At the end of the day I think that it really depends on your testing/specifying style. If it's simple (simple specification structure, setups, expectations, ...) then both libraries will appear very similar. Otherwise, both have their take on how things should be done. As a last example of this you can have a look at tagging: in ScalaTestand in specs.

归根结底，我认为这真的取决于您的测试/指定风格。如果它很简单（简单的规范结构、设置、期望等），那么这两个库将看起来非常相似。否则，双方都对应该如何做事情有自己的看法。作为最后一个示例，您可以查看标记：在ScalaTest和specs 中。

I hope this helps.

我希望这有帮助。

回答by Daniel C. Sobral

As far as I know, barring a few highly specialized features, it comes down to personal preference according to the style.

据我所知，除了一些高度专业化的功能外，根据风格归结为个人喜好。

回答by Grav

IDE support may be another point

IDE 支持可能是另一点

I've been trying to get Specs to work with Eclipse through JUnit, and I found the official solution to be a bit "hacky". Specs setup: http://code.google.com/p/specs/wiki/RunningSpecs#Run_your_specification_with_JUnit4_in_Eclipse

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

ScalaTest's integration (also through JUnit) with seems a bit less hacky. Still, I haven't got any of them to work as well as JUnit and Java.

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

ScalaTest setup: http://groups.google.com/group/scalatest-users/web/running-scalatest-from-eclipse

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

回答by sebi

If one decision factor is the compile time, scalatest seems to perform better.

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

We're currently using specs2 in our project, but suffer from slow compile times in tests. I just finished a POC on moving to scalatest and saw compile times drop by a factor of about 0.82 just by switching the 2 frameworks in some of our sources.

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