行为驱动开发 （BDD）是一个协作过程 ，产品所有者，开发人员和测试人员可以合作交付可为业务带来价值的软件。

BDD是 测试驱动开发 （TDD） 的合理下一步 。

行为驱动的发展

本质上，BDD是一种交付需求的方法。 但不仅有任何要求，还包括可执行要求！ 使用BDD，您可以以可以针对该软件运行的格式来编写方案 ，以确定该软件是否按预期运行。

情境

场景以“ 给定，何时，然后”格式（也称为Gherkin）编写：

Given the ATM has $250
And my balance is $200
When I withdraw $150
Then the ATM has $100
And my balance is $50

Give表示初始上下文， When表示发生了有趣的事件， 然后断言了预期的结果。 并且可以用来代替重复的关键字，以使方案更具可读性。

Give / When / Then是一个非常强大的习惯用法 ，几乎可以描述任何要求。 这种格式的场景也很容易解析，因此我们可以自动运行它们。

BDD场景对开发人员非常有用，因为它们提供了有关故事是否完成的快速而明确的反馈。 不仅可以提供主要成功方案，还可以提供替代方案和异常方案 ，如滥用案例 。 后者要求产品负责人不仅要与测试人员和开发人员合作，还要与安全专家合作。 结果是， 管理安全要求变得更加容易。

尽管BDD实际上是关于协作过程的，而不是关于工具的，但在本文的其余部分中，我将专注于工具。 请记住， 工具永远无法挽救您，而沟通和协作则可以 。 消除了这一警告，让我们开始使用一些开源工具来实现BDD。

杰贝夫

JBehave是Java的BDD工具。 它从故事文件中解析场景，将它们映射到Java代码，通过JUnit测试运行它们，并生成报告。

JUnit的

这是我们使用JUnit运行故事的方式：

@RunWith(AnnotatedEmbedderRunner.class)
@UsingEmbedder(embedder = Embedder.class, generateViewAfterStories = true,ignoreFailureInStories = true, ignoreFailureInView = false, verboseFailures = true)
@UsingSteps(instances = { NgisRestSteps.class })
public class StoriesTest extends JUnitStories {@Overrideprotected List<String> storyPaths() {return new StoryFinder().findPaths(CodeLocations.codeLocationFromClass(getClass()).getFile(),Arrays.asList(getStoryFilter(storyPaths)), null);}private String getStoryFilter(String storyPaths) {if (storyPaths == null) {return '*.story';}if (storyPaths.endsWith('.story')) {return storyPaths;}return storyPaths + '.story';}private List<String> specifiedStoryPaths(String storyPaths) {List<String> result = new ArrayList<String>();URI cwd = new File('src/test/resources').toURI();for (String storyPath : storyPaths.split(File.pathSeparator)) {File storyFile = new File(storyPath);if (!storyFile.exists()) {throw new IllegalArgumentException('Story file not found: ' + storyPath);}result.add(cwd.relativize(storyFile.toURI()).toString());}return result;}@Overridepublic Configuration configuration() {return super.configuration().useStoryReporterBuilder(new StoryReporterBuilder().withFormats(Format.XML, Format.STATS, Format.CONSOLE).withRelativeDirectory('../build/jbehave')).usePendingStepStrategy(new FailingUponPendingStep()).useFailureStrategy(new SilentlyAbsorbingFailure());}}

这使用JUnit 4的@RunWith注释来指示将运行测试的类。 AnnotatedEmbedderRunner是JBehave提供的JUnit Runner 。 它寻找@UsingEmbedder批注以确定如何运行故事：

• generateViewAfterStories指示JBehave在运行故事后创建测试报告
• 当故事失败时， ignoreFailureInStories防止JBehave引发异常。 这对于与Jenkins集成至关重要，如下所示

@UsingSteps批注将方案中的步骤链接到Java代码。 下面的更多内容。 您可以列出多个类别。

我们的测试类重新使用了JBehave的JUnitStories类，这使得运行多个故事变得容易。 我们只需要实现两种方法： storyPaths()和configuration() 。

storyPaths()方法告诉JBehave在哪里找到要运行的故事。 我们的版本有点复杂，因为我们希望能够从我们的IDE和命令行中运行测试，并且因为我们希望能够运行所有故事或特定子集。

我们使用系统属性bdd.stories指示要运行的故事。 这包括对通配符的支持。 我们的命名约定要求故事文件名以角色开头，因此我们可以使用-Dbdd.stories=wanda_*类的-Dbdd.stories=wanda_*轻松运行单个角色的所有故事。

configuration()方法告诉JBehave 如何运行故事并对其进行报告 。 我们需要XML输出，以便在Jenkins中进行进一步处理，如下所示。

感兴趣的一件事是报告的位置。 JBehave支持Maven，这很好，但是他们假设每个人都遵循Maven约定，但事实并非如此。 默认情况下，输出进入一个名为target的目录，但是我们可以通过指定相对于target目录的路径来覆盖该目录。 我们使用Gradle代替Maven，并且Gradle的临时文件进入build目录，而不是target 。 更多关于Gradle的信息。

脚步

现在我们可以运行我们的故事，但是它们会失败。 我们需要告诉JBehave如何将场景中的Given / When / Then步骤映射到Java代码。 步骤类确定可以在方案中使用的词汇表。 因此，他们定义了一种用于接受测试我们的应用程序的领域特定语言 （DSL）。

我们的应用程序具有RESTful接口，因此我们编写了通用的REST DSL。 但是，由于REST中的HATEOAS约束，客户端需要大量调用才能发现其应使用的URI。 这样写场景变得很无聊和重复，因此我们在REST DSL之上添加了特定于应用程序的DSL。 这使我们可以用产品负责人理解的术语来编写方案 。

在通用REST步骤之上分层特定于应用程序的步骤具有一些优点：

• 实施新的特定于应用程序的DSL很容易，因为它们只需要调用REST特定的DSL
• REST专用的DSL可以与其他项目共享

Gradle

有了步骤，我们可以从我们最喜欢的IDE中运行我们的故事。 这对开发人员来说效果很好，但是不能用于持续集成 （CI）。

我们的CI服务器运行的是无头构建，因此我们需要能够从命令行运行BDD方案。 我们使用Gradle使构建自动化，并且Gradle已经可以运行JUnit测试。 但是，我们的构建是一个多项目构建。 在构建所有项目，创建发行版并启动应用程序之前，我们不希望运行BDD方案。

因此，首先，我们在包含BDD故事的项目上禁用运行测试：

test {onlyIf { false } // We need a running server
}

接下来，我们创建另一个可以在启动应用程序后运行的任务：

task acceptStories(type: Test) {ignoreFailures = truedoFirst {// Need 'target' directory on *nix systems to get any outputfile('target').mkdirs()def filter = System.getProperty('bdd.stories') if (filter == null) {filter = '*'}def stories = sourceSets.test.resources.matching { it.include filter}.asPathsystemProperty('bdd.stories', stories)}
}

在这里，我们看到了Gradle的力量。 我们定义了一个Test类型的新任务，以便它已经可以运行JUnit测试。 接下来，我们使用一些Groovy脚本配置该任务。

首先，我们必须确保target目录存在。 我们不需要甚至不需要它，但是如果没有它，JBehave将无法在* nix系统上正常工作。 我想那是一点Maven主义

接下来，再次使用bdd.stories系统属性添加对运行故事子集的支持。 我们的故事文件位于src/test/resources ，因此我们可以使用标准Gradle test 源集轻松访问它们。 然后，我们为运行测试的JVM设置系统属性bdd.stories 。

詹金斯

现在，我们可以从IDE和命令行运行BDD方案。 下一步是将它们集成到我们的CI版本中。

我们可以将JBehave报告存档为工件，但是，老实说，JBehave生成的报告并不是很好。 幸运的是，JBehave团队还维护了Jenkins CI服务器的插件 。 该插件需要事先安装xUnit插件 。

将xUnit和JBehave插件安装到jenkins中之后，我们可以配置Jenkins作业以使用JBehave插件。 首先，添加xUnit生成后操作。 然后，选择JBehave测试报告。

使用此配置，在我们的BDD故事上运行JBehave的输出看起来像常规单元测试的输出：

请注意，图中的黄色部分表示待处理的步骤。 这些用于BDD场景，但在Java Steps类中没有对应的对象。 未完成的步骤显示在测试结果的“ Skip列中：

请注意，JBehave Jenkins插件如何将故事转换为测试，将场景转换为测试方法。 这样可以很容易地发现哪些方案需要更多工作。

尽管JBehave插件运行良好，但是有两点可以改进：

• 测试的输出未显示。 这使得很难弄清楚场景失败的原因。 因此，我们还存档了JUnit测试报告
• 如果将ignoreFailureInStories配置为false ，则JBehave会在失败时引发异常，该异常会截断XML输出。 然后，JBehave Jenkins插件将无法再解析XML（因为它的格式不正确），并且会完全失败，从而使您没有测试结果

所有这些都是不便之处，我们对自动化的BDD方案感到非常满意。

祝您编程愉快，别忘了分享！

参考： 安全软件开发博客上来自JCG合作伙伴 Remon Sinnema的JBehave，Gradle和Jenkins的行为驱动开发（BDD） 。