Java的BDD框架之间有什么区别？[关闭]

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

例如，我在这里找到了其中一些。

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

我刚刚比较了三种Java BDD框架。显然，我的发现的使用期限很短。

协和

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

EasyB

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

杰贝夫

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

我没有如我所愿尝试JDave的Cuke4Duke的机会，但此时可能会推动JBehave。

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

• 开发活动，例如有可能是新版本还是最近发行的2年了。
• 成熟度，例如已经存在多长时间了，是否有教程甚至书籍可用。（我不读这些书，这只是通过的标志。）
• 工具支持，例如是否有Eclipse插件，Ant支持等
• 依赖项的大小，我不喜欢它们自己附带的框架。例如，我想自己选择模拟框架。
• 许可证，这对我来说很重要，因为我所工作的公司具有法律条款。
• 与相关工具的兼容性，例如它是否使用Gherkin语言。

从某些框架中，我看了一下

• 本能 不好：上一次活动是2010年3月，良好：ASF许可证
• JDave 不好：带有匹配器和模拟，很好：上一次活动2011年1月，ASF许可证
• easyb 不好：上次活动是2010年10月，不确定：它使用Groovy。可能没问题，但就我而言，采用该问题。
• beanspec 不好：2007年只有一个版本，已经死了
• bdoc bad：上次活动是2010年1月，不确定：看起来像是从代码中创建报告一样。
• spock 不好：也许有点极端，这是一个完整的测试框架，不仅是BDD，还不错：非常活跃，非常酷。
• jbehave，Java中所有BDD的“母亲”，不好：非常强大=复杂，不兼容的许可证（对我来说），几乎每个测试库都附带了，还有很多，很好：基于RSpec并因此兼容，eclipse插件，maven集成，非常活跃的社区
• ginkgo4j，一种Java的BDD框架，它也基于Ruby的RSpec，但使用Java lambda（而不是注释）来允许您创建高度上下文相关，可读性强的测试。简单。很强大。开源Apache 2许可证。

关于模拟：您当然也需要一个模拟框架。BDD框架只是帮助您编写规范，但是某些测试将需要模拟或存根，尤其是。自上而下设计时（从概述到详细信息）。

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

这是有关Concordion与Cucumber和基于Java的验收测试的有趣链接

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

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

如果我已经在使用模拟库（例如Mockito），则使用BDD框架有意义吗？

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

我最初使用简单的jUnit进行BDD，但是最近我一直在研究JDave，因为它与我使用jUnit所做的差不多1：1。它也运行在jUnit之上，因此它已经可以在Eclipse上运行，并且易于配置以在诸如Hudson的连续集成系统上运行。不能与其他人真正比较，但是到目前为止，我在JDave方面的经验一直很好。

哦，使用模拟绝不是愚蠢的主意！它们与TDD / BDD无关，它们的目的是减轻总体的测试负担。

哇，我看到话题很热，好答案很多...

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

“ 行为驱动开发”一文概述了这一概念，并链接了一些不错的文章（例如Andrew Glover撰写的文章）。而且，关于该线程的主题，它给出了一个相当全面的（我想是）BDD框架列表，其中很多是Java的。
它不能解决选择框架的问题，但至少可以简化搜索...

由于BDD高度依赖于测试代码的可读性，因此我认为一个不错的选择标准是看一下快速导览/教程，看看哪种看起来更适合您的风格。其他条件可能是事实，即您熟悉的框架利用工具（单元测试，模拟），IDE的使用等等。

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

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

结果

我的团队已经使用JBehave已有一段时间了。它使用纯文本文件存储规范。然后，可以通过某种方法执行每个步骤（给出，何时，然后），该方法可以从该步骤中提取参数。场景可以缩进和格式化，如果客户想要验证场景，这会很有帮助。

也有一些问题。我们已切换到Java6。有时在执行过程中会忽略某些场景步骤。找出错误所在可能会造成很多麻烦。

我的团队成功地使用了JBehave-我们在使用EasyB之后将其转移到JBehave上，发现纯文本脚本文件更易于处理。