Java 的 BDD 框架之间有什么区别？

What are the differences between BDD frameworks for Java?

提问by user68109

What are the pros and cons of each Behavior Driven Development(BDD) framework for Java?

Java的每个行为驱动开发(BDD) 框架的优缺点是什么？

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)?

如果我已经使用了一个模拟库（例如Mockito），那么使用 BDD 框架是否有意义？

回答by Esko

I originally did my BDD with plain jUnit but I've been looking at JDavelately 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.

我最初使用普通 jUnit 进行 BDD，但最近我一直在研究JDave，因为它与我使用 jUnit 所做的几乎是 1:1 的。它还在 jUnit 之上运行，因此它已经可以在 Eclipse 上运行，并且还可以轻松配置为在 Hudson 等持续集成系统上运行。无法真正将它与其他人进行比较，但到目前为止我在 JDave 上的体验一直很好。

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.

哦，使用模拟从来都不是一个愚蠢的想法！它们与 TDD/BDD 无关，它们的目的是减轻一般的测试负担。

回答by PhiLho

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.

讽刺的是，我最近发现了 BDD 并发现这个概念很有趣。嘿，它强制编写测试......和规范！令人惊讶的是，后者在某些项目中也可能缺失……或者只是缺乏 BDD 强制引入的精度。

The Behavior Driven Developmentarticle 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...

在驱动开发行为本文总结了概念，并链接到一些好文章（如一个由安德鲁·格洛弗写的）。此外，对于这个线程的主题，它提供了一个相当全面（我想）的 BDD 框架列表，其中很多是用于 Java 的。
它并没有解决选择框架的问题，但至少它会简化搜索......

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.

由于 BDD 在很大程度上依赖于测试代码的可读性，我认为一个很好的选择标准是查看快速教程/教程，看看哪个更适合您的风格。其他标准可能是框架利用您熟悉的工具（单元测试、模拟）、与 IDE 的使用等等。

回答by Boris Pavlovi?

My team have been using JBehavefor 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.

我的团队使用JBehave已经有一段时间了。它使用纯文本文件来存储规范。每个步骤（Given、When、Then）都由某种方法执行，该方法可以从步骤中提取参数。场景可以缩进并格式化，如果客户想要验证它们，这会很有帮助。

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.

也有一些问题。我们已经切换到 Java 6。有时在执行过程中会忽略一些场景步骤。找出错误在哪里可能会导致很多麻烦。

回答by Pascal Thivent

What's the best BDD framework to use with Java? Why? What are the pros and cons of each framework?

与 Java 一起使用的最佳 BDD 框架是什么？为什么？每个框架的优缺点是什么？

Here is an interesting link about Concordion vs. Cucumber and Java based Acceptance Testing

这是一个关于Concordion vs. Cucumber 和基于 Java 的验收测试的有趣链接

I've found couple of them here, but I'm not sure which one to choose.

我在这里找到了其中的几个，但我不确定该选择哪一个。

Really, look at the one mentioned above.

真的，看看上面提到的那个。

Does it make sense to use a BDD framework if I already use a mocking library (e.g. Mockito)?

如果我已经使用了一个模拟库（例如 Mockito），那么使用 BDD 框架是否有意义？

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.

简短的回答：是的，肯定的。实际上，使用 BDD 框架的验收测试和使用模拟对象进行隔离的单元测试是如此不同，以至于我真的不明白这个问题。验收测试是黑盒测试，测试用于验证业务功能是否正常工作，理想情况下由业务分析师编写。使用模拟的隔离单元测试是白盒测试，测试用于验证单元是否正常工作并由开发人员编写。两者都是有用的但它们具有完全不同的用途。换句话说，使用 Mockito 根本不会取代 BDD 框架，反之亦然。

回答by Matt Green

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.

我的团队成功地使用了 JBehave - 我们在使用 EasyB 后转向它，发现纯文本场景文件更容易处理。

回答by Caoilte

I've just finished comparing three BDD frameworks for Java. Obviously my findings have a fairly short use-by date.

我刚刚完成了对 Java 的三个 BDD 框架的比较。显然，我的发现有一个相当短的使用期限。

Concordion

协和

• Very flexible
• Very pretty report output
• Nice plugin framework
• Poorly documented. I had to read the source to figure it out (luckily its extremely good quality).
• Fixtures seemed likely to end up tightly coupled to the html.

• 非常灵活
• 非常漂亮的报告输出
• 不错的插件框架
• 记录不佳。我必须阅读源代码才能弄清楚（幸运的是它的质量非常好）。
• 夹具似乎很可能最终与 html 紧密耦合。

EasyB

易B

• Very shallow learning curve (even for non-Groovy Developers)
• Extremely powerful DBUnit integration
• Apparently no support for parameters (leads to either very vague stories or duplication between text and code (edit: actually there is but the documentation for it was very well hidden.)
• Story and Code are very tightly coupled (same file)
• Very basic report output
• Couldn't get IntelliJ plugin to work
• Inactive community (Maven plugin seems to have been broken for three months - not many code examples to draw on)

• 非常浅的学习曲线（即使对于非 Groovy 开发人员）
• 极其强大的 DBUnit 集成
• 显然不支持参数（导致非常模糊的故事或文本和代码之间的重复（编辑：实际上有，但它的文档被很好地隐藏了。）
• Story 和 Code 是非常紧密耦合的（同一个文件）
• 非常基本的报告输出
• 无法让 IntelliJ 插件工作
• 不活跃的社区（Maven 插件似乎已经坏了三个月 - 没有多少代码示例可以借鉴）

JBehave

JBehave

• Extremely powerful and flexible (eg reduction of boiler-plate through composition of stories as pre-requisites)
• Extensive (if fragmented) documentation and examples
• Extensive (if overwhelming) support for different frameworks and environments
• Excellent separation of story files from code
• Looks to have a pretty active community and much more examples and discussion of it on web.
• Quite a steep learning curve (took me 3-4 times longer to figure out than Concordion/EasyB)

• 极其强大和灵活（例如，通过将故事组合作为先决条件来减少样板文件）
• 广泛的（如果是零散的）文档和示例
• 对不同框架和环境的广泛（如果是压倒性的）支持
• 故事文件与代码的完美分离
• 看起来有一个非常活跃的社区和更多的例子和网络上的讨论。
• 相当陡峭的学习曲线（比 Concordion/EasyB 花费了我 3-4 倍的时间来弄清楚）

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.

我没有机会像我希望的那样尝试 JDave 的 Cuke4Duke，但此时可能会推动 JBehave。

回答by Peter Kofler

"pros and cons" might be different things for different people. I usually have a look at

“利弊”对于不同的人来说可能是不同的。我通常看看

• development activity, e.g. are new releases likely or is the last release 2 years old.
• maturity, e.g. how long has it been around, are there tutorials and maybe even books available. (I don't read these books, it's just a sign of adoption.)
• tool support, e.g. is there an Eclipse plugin, Ant support, etc
• size of the dependencies, I don't like frameworks that come with everything of their own. e.g. I want to chose my mocking framework myself.
• kind of license, this is important for me because of legal terms in the company I work for.
• compatibility with related tools, e.g. does it use Gherkin language or not.

• 开发活动，例如可能是新版本或者是 2 年前的最后一个版本。
• 成熟度，例如它已经存在多久了，是否有教程甚至书籍可用。（我不读这些书，这只是采用的标志。）
• 工具支持，例如是否有 Eclipse 插件、Ant 支持等
• 依赖的大小，我不喜欢自带一切的框架。例如，我想自己选择我的模拟框架。
• 一种许可证，这对我很重要，因为我工作的公司的法律条款。
• 与相关工具的兼容性，例如它是否使用 Gherkin 语言。

And from some frameworks I had a look at

从一些框架我看了

• Instinctbad: last activity Mar 2010, good: ASF license
• JDavebad: comes with matchers and mocks, good: last activity Jan 2011, ASF license
• easybbad: last activity Oct 2010, not sure: it uses Groovy. This might be ok, but would be a problem for adoption in my case.
• beanspecbad: only one version in 2007, this is dead
• bdocbad: last activity Jan 2010, not sure: it looks like going the other way, creating a report from the code.
• spockbad: maybe a bit extreme, this is a complete testing framework, not only BDD, good: very active, very cool.
• jbehave, the "mother" of all BDD in Java, bad: very powerful = complex, incompatible license (for me), comes with almost every test library and much more, good: based on RSpec and therefore compatible, eclipse plugins, maven integration, very active community
• ginkgo4j, a BDD framework for Java also based on Ruby's RSpec but using Java lambda's (instead of annotations) to allow you to create highly contextual, highly readable tests. Simple. Very powerful. Open source Apache 2 license.

• 本能不好：最后一次活动 2010 年 3 月，好：ASF 许可证
• JDave不好：带有匹配器和模拟，好：2011 年 1 月的最后一次活动，ASF 许可证
• easybbad：2010 年 10 月的最后一次活动，不确定：它使用 Groovy。这可能没问题，但在我的情况下会成为采用的问题。
• beanspec不好：2007 年只有一个版本，这个已经死了
• bdocbad：2010 年 1 月的最后一次活动，不确定：它看起来像是走另一条路，从代码创建报告。
• spockbad：可能有点极端，这是一个完整的测试框架，不仅是 BDD，good：非常活跃，非常酷。
• jbehave，Java 中所有 BDD 的“母亲”，坏的：非常强大 = 复杂，不兼容的许可证（对我来说），几乎每个测试库都带有，好：基于 RSpec，因此兼容，eclipse 插件，maven 集成, 非常活跃的社区
• ginkgo4j，一个用于 Java 的 BDD 框架也基于 Ruby 的 RSpec，但使用 Java lambda（而不是注释）来允许您创建高度上下文、高度可读的测试。简单的。很强大。开源 Apache 2 许可证。

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).

关于模拟：您肯定还需要一个模拟框架。BDD 框架只是帮助您编写规范，但有些测试需要模拟或存根，尤其是。当您自上而下设计时（从概览到细节）。

回答by Paul Verest

I tried Cucumber-JVM(previously developed as Cuke4Duke). It uses Gherkin DSL for specification, stored as plain text.

我尝试了Cucumber-JVM（以前开发为 Cuke4Duke）。它使用 Gherkin DSL 进行规范，以纯文本形式存储。

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.

它可以作为 JUnit 测试运行。所以开始使用它的唯一问题是让业务人员或产品经理在 Sources 中读/写 .features。

Results

结果