Java 的 BDD 框架之间有什么区别？
What are the pros and cons of each Behavior Driven Development (BDD) framework for Java?
I've found some of them here, for example.
Does it make sense to use a BDD framework if I already use a mocking library (e.g. Mockito)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我的团队成功地使用了 JBehave - 我们在使用 EasyB 后转向它，并发现纯文本场景文件更容易处理。
My team have used JBehave with success - we moved to it after using EasyB and found the plain text scenario files easier to deal with.
我刚刚比较了三个 Java BDD 框架。 显然我的发现的使用期限相当短。
Concordion
EasyB
JBehave
我没有机会像我希望的那样尝试 JDave 的 Cuke4Duke，但此时可能会推动 JBehave。
I've just finished comparing three BDD frameworks for Java. Obviously my findings have a fairly short use-by date.
Concordion
EasyB
JBehave
I didn't have the chance to try out Cuke4Duke of JDave as I would have liked, but will probably push for JBehave at this time.
“利弊”对于不同的人来说可能是不同的。 我通常会查看
我从一些框架中了解了
关于模拟：您肯定还需要一个模拟框架。 BDD 框架只是帮助您编写规范，但某些测试将需要模拟或存根，尤其是。 当您自上而下设计时（从概述到细节）。
"pros and cons" might be different things for different people. I usually have a look at
And from some frameworks I had a look at
Concerning the mocks: You definitely need a mocking framework as well. The BDD frameworks just help you in writing the specs, but some tests will need mocks or stubs, esp. when you design top down (from overview to detail).
这是一个关于 Concordion 与基于 Cucumber 和 Java 的验收测试
确实如此，看看上面提到的那个。
简短的回答：是的，当然。 实际上，使用 BDD 框架进行的验收测试和使用模拟对象进行隔离的单元测试是如此不同，以至于我并没有真正理解这个问题。 验收测试是黑盒测试，测试用于验证业务功能是否正常工作，并且最好由业务分析师编写。 使用模拟进行隔离的单元测试是白盒测试，测试用于验证单元是否正常工作并且是由开发人员编写的。 两者都很有用，但它们的目的完全不同。 换句话说，使用 Mockito 根本不会取代 BDD 框架，反之亦然。
Here is an interesting link about Concordion vs. Cucumber and Java based Acceptance Testing
Really, look at the one mentioned above.
Short answer: yes, definitely. Actually, acceptance testing using a BDD framework and unit testing in isolation using mock objects are so different that I don't really get the question. Acceptance testing is black box testing, tests are used to verify that a business feature is working and are ideally written by business analyst. Unit tests in isolation using mocks is white box testing, tests are used to verify that a unit is working and are written by developers. Both are useful buty they have totally different purposes. In other words, using Mockito doesn't replace a BDD framework at all and the inverse is also true.
我最初使用普通的 jUnit 进行 BDD，但最近我一直在查看 JDave 因为它几乎是 1:1我用 jUnit 做了什么。 它还在 jUnit 之上运行，因此它已经可以在 Eclipse 上运行，并且也可以轻松配置以在 Hudson 等持续集成系统上运行。 无法与其他人进行比较，但到目前为止我对 JDave 的体验一直很好。
哦，使用模拟从来都不是一个愚蠢的想法！ 它们并不专门与 TDD/BDD 相关，它们的目的是减轻一般测试的负担。
I originally did my BDD with plain jUnit but I've been looking at JDave lately because it's almost 1:1 to what I was doing with jUnit. It also runs on top of jUnit so it already works on Eclipse and is also easy to configure to work on continuous integration systems such as Hudson. Can't really compare it with others but my experiences with JDave have been good so far.
Oh and it's never a stupid idea to use mocks! They're not tied to TDD/BDD specifically, their purpose is to ease the burden of testing in general.
哇，我看到这个话题很热门，有很多好的答案……
讽刺的是，我最近发现了 BDD，并发现这个概念很有趣。 嘿，它强制编写测试......和规范！ 尽管看起来令人惊讶，但后者在某些项目中也可能缺失……或者只是缺乏 BDD 强制引入的精确性。
行为驱动开发文章总结了这一概念以及一些好文章的链接（比如 Andrew Glover 写的一篇）。 此外，对于本线程的主题，它提供了相当全面的（我认为）BDD 框架列表，其中很多都是针对 Java 的。
它不能解决选择框架的问题，但至少可以简化搜索...
由于 BDD 严重依赖于测试代码的可读性，我认为一个好的选择标准是查看快速浏览/教程并了解哪一款看起来更适合您的风格。
其他标准可能是框架利用您熟悉的工具（单元测试、模拟）、IDE 的使用等等。
Wow, I see the topic is hot, lot of good answers...
Irony aside, I recently discovered BDD and found the concept interesting. Hey, it forces to write both tests... and specifications! As surprising as it might seem, the latter can be also missing in some projects... Or just lacking the precision that BDD forces to introduce.
The Behavior Driven Development article summarizes the concept and links to some good articles (like the one written by Andrew Glover). Moreover, to the topic of this thread, it gives a rather comprehensive (I suppose) listing of BDD frameworks, a good number of them being for Java.
It doesn't solve the problem of choosing the framework but at least it will ease the search...
Since BDD relies heavily on readability of test code, I suppose a good criterion of choice is to look at the quick tours/tutorial and see which one seems the more fitting your style.
Other criteria could be the fact a framework leverage tools you are familiar with (unit test, mocking), usage with IDE, and so on.
我尝试了 Cucumber-JVM （之前开发为 Cuke4Duke）。
它使用 Gherkin DSL 进行规范，以纯文本形式存储。
它可以作为 JUnit 测试运行。 因此，开始使用它的唯一问题是让业务人员或产品经理在源中读/写.features。
结果
I tried Cucumber-JVM (previously developed as Cuke4Duke).
It uses Gherkin DSL for specification, stored as plain text.
It can be run as a JUnit test. So the only problem to start using it is to make business people or Product Manager read/write .features in Sources.
Results
我的团队使用 JBehave 一段时间了。 它使用纯文本文件来存储规格。 然后，每个步骤（Given、When、Then）都由某种可以从步骤中提取参数的方法执行。 场景可以缩进并且格式良好，如果客户想要验证它们，这会很有帮助。
也存在一些问题。 我们已切换到Java 6。有时在执行过程中会忽略某些场景步骤。 找出错误所在可能会带来很多麻烦。
My team have been using JBehave for some time. It uses plain text files to store specifications. Every step (Given, When, Then) is then executed by a certain method which can extract parameters from the step. Scenarios can be indented and well formatted which helps a lot if clients want to verify them.
There are some problems, too. We have switched to Java 6. Sometimes some scenario steps are ignored during execution. It may cause a lot of trouble figuring out where's the bug.