ScalaTest和Scala Specs单元测试框架有什么区别？ [英] What’s the difference between ScalaTest and Scala Specs unit test frameworks?
问题描述
这两个都是用Scala编写的BDD（行为驱动开发）单元测试框架。和规格 建立在之上也可能涉及 ScalaTest 框架。但是规格提供ScalaTest不？有什么区别？
Specs和ScalaTest都是快乐用户的好工具，但它们在几个方面有所不同。你可能想选择一个作为你在Scala中的主要测试工具，但不需要放弃另一个，因为你可以使用两者。例如，如果你喜欢ScalaTest的 FeatureSpec 语法和specs'Mockito语法，你可以把两个jar文件在类路径中，并同时使用两者。在这里，我将尝试捕获规范和ScalaTest之间注意到的主要设计理念差异。
这些工具之间的主要哲学差异是规范是为行为驱动开发（BDD），而ScalaTest是更通用的。 ScalaTest提供了可以混合在一起的特征，以便在测试类（包括BDD）中获得您喜欢的行为，并且如果您想要不同的东西，也可以轻松地定义自己的行为。
ScalaTest通过其 Spec ， FeatureSpec ，，WordSpec支持BDD ， FlatSpec 和 GivenWhenThen traits，还有特性，你可以混合使用一个很好的匹配语法。如果你喜欢应该，你在ShouldMatchers中混合。如果你喜欢必须，你在 MustMatchers 中混合。但是如果你喜欢BDD但不喜欢matcher语法，你可以只使用一个ScalaTest的Spec traits而不混合在匹配器trait。规范具有您扩展的规范类，并且必须在匹配器表达式中使用单词必须。一个很大的哲学差异在这里很明显，ScalaTest给你更多的选择。为了使这个选择空间更容易导航，我在这里提供一个决策树：
http://www.scalatest.org/quick_start
ScalaTest和specs之间的匹配语法也不同。在ScalaTest中，我试图看看我可以用操作符符号去多远，并且最终与匹配器表达式读得非常像英语句子，在单词之间有空格。 Specs匹配器语法与camel case一起运行的话更多。
规格比ScalaTest更多的匹配，我认为反映了设计态度的差异。我实际上削减了大约2/3的匹配器语法我构建和考虑发布。我将在未来的版本中添加更多的匹配器，但是希望确保我知道用户在添加它之前实际上想要的东西。但是ScalaTest的匹配器包括一个动态属性匹配器语法占用了一些松弛。例如在Specs中你可以写在 java.io.File ：
file must beDirectory
这将调用 isDirectory 并确保它是真的。 ScalaTest目前没有任何特殊的匹配器 java.io.Files ，但是在ScalaTest中，你可以使用如下的动态检查：
文件必须是（'目录）
每当你在之后传递一个符号，它将使用反射寻找一个名为的方法或字段或名为 isDirectory 的方法。还有一种方法使这个静态，通过定义一个 BePropertyMatcher （通常只需要2或3行代码）。因此，基本上在ScalaTest中我尝试提供更多的功能与更少的API。
规范和ScalaTest
之间的另一个一般设计态度差异涉及隐式转换。默认情况下，当你使用ScalaTest时，你只能得到一个隐式转换，这是在所有的 === 运算符。 （如果你需要，你可以用一行代码关闭这个隐式转换。你需要这样做的唯一原因是如果你想测试一些有自己的 == = 运算符，并且得到冲突。）ScalaTest定义了许多其他隐式转换，但是要使用它们，您需要通过混合特征或执行导入来显式地邀请它们到代码中。当你在规范中扩展类 Specification 时，我认为你默认几乎得到几十个隐式转换。我不确定在实践中有多重要，但我认为人们会想要测试使用自己的含义的代码，有时测试框架的含义和生产代码之间可能会有冲突。当发生这种情况时，我认为在ScalaTest中解决问题可能比规范更容易。
我注意到的设计态度的另一个区别是操作符的舒适。我的一个目标是，任何程序员看着别人的测试代码，使用ScalaTest将能够猜到什么意思，没有在ScalaTest文档中查找任何东西。我想让ScalaTest客户端代码丢失明显。目标表现的一种方式是ScalaTest对操作符非常保守。我只在ScalaTest中定义了五个运算符：
-
=== -
>，意味着大于 -
-
> =，大于或等于 -
< =，小于或等于。
。所以这些东西看起来像什么意思。如果您在其他人的代码中看到：
结果应为<= 7
我希望你不需要运行到API文档来猜测< = 表示。相比之下，规范对操作符更自由。没有什么错，但它是一个区别。操作符可以使代码更简洁，但是折衷是当你发现 - > - ，> > ， | ， |> ，！或 ^^^ （在规格中都有特殊含义）。
$ b $另一个哲学上的区别是，我试着在ScalaTest中稍微简单一些，当你需要共享一个fixture时使用一个函数式样，而Specs默认继承了
setUp的传统和 tearDown 方法，在每个测试之前，您重新分配vars。然而，如果你想测试这种方式，它也很容易在ScalaTest。您只需要在 BeforeAndAfter trait中混合。 有关ScalaTest的更多信息，您可以观看Get更高的ScalaTest演示我在2009年Devoxx会议在这里：
http://parleys.com/play/514892260364bc17fc56bde3/chapter0/about
Both are BDD (Behavior Driven Development) capable unit test frameworks for Scala written in Scala. And Specs is built upon may also involve the ScalaTest framework. But what does Specs offer ScalaTest doesn't? What are the differences?
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 FeatureSpec syntax 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.
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.
ScalaTest supports BDD through its Spec, FeatureSpec, WordSpec, FlatSpec, and GivenWhenThen traits, 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:
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.
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:
file must beDirectory
This will invoke the isDirectory and make sure it is true. ScalaTest does not have any special matchers for java.io.Files currently, but in ScalaTest, you could just use a dynamic check like this:
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 directory or 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.
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 Specification in 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.
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:
===, 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.
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 setUp and tearDown approach 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 BeforeAndAfter trait.
For more insight into ScalaTest, you can watch the "Get Higher with ScalaTest" presentation I gave at the 2009 Devoxx conference here:
http://parleys.com/play/514892260364bc17fc56bde3/chapter0/about
这篇关于ScalaTest和Scala Specs单元测试框架有什么区别？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
