问组织JBehave故事

EN

@MrWiggles

正如t0rx告诉你的那样，你很幸运有QA来写故事/场景。

关于你的问题：

行为驱动开发鼓励您通过以文本格式表达所需行为的场景来开始定义故事。

您可以通过在Maven (pom.xml)中进行配置来运行JBehave故事。

您可以在包结构中创建一个文件夹来存储故事文件，如下所示：

Your_Project
      |
      |
      |--Source_Code
      |
      |--Stories
      |
      |--Testing
      |
      *pom.xml

通过在maven中配置你的故事，每次你构建项目时，它都会给出成功和失败的故事/场景结果。

QA将更新文件夹Stories中的场景，开发人员将通过省略现有步骤来逐步实现场景(这些步骤已经开发，并在其他场景中出现)。

QA只需运行场景/故事，他将以文本(可理解的)格式找到结果。

如下所示：

测试级别中的行为驱动开发。

​

JBehave的一些特性集中在易于组织上。

• Annotation-based配置和步骤类规范
• 依赖注入支持，允许通过您最喜欢的容器(Guice, PicoContainer, Spring)组合配置和步骤实例。
• 可扩展故事报告:输出以不同人类可读的基于文件的格式(HTML, TXT, XML)执行的故事。完全可设置样式的视图。挂起步骤的
• Auto-generation，因此构建不会因缺少的步骤而中断，但可以选择为挂起步骤配置中断构建。用户故事的
• Localisation，允许它们用任何语言编写。
• 集成开发环境集成: stories可以作为JUnit测试或其他基于注释的单元测试框架运行，提供与您喜爱的集成开发环境的轻松集成。
• Ant集成:允许通过Ant任务运行故事
• Maven集成:允许在给定的构建阶段

通过Maven插件运行故事

如果您足够幸运地让产品负责人或QA编写故事，那么您可能希望它们位于源代码存储库的特定区域，这样您就可以独立于主要源代码控制访问(如果您这样做，还可以让您在何时触发CI构建方面具有更大的灵活性)。

你可能会发现许多来回的方法来最小化开发人员必须编写的新步骤的数量(例如，使用十种不同的方法来停止它们来编写相同的步骤)，因此还需要运行挂起的步骤而不会在场景中失败(这是默认的开箱即用)。

另一种方法是QA/产品所有者将场景发送给开发人员，然后开发人员在添加到源代码控制之前对其进行清理，但这会将工作放回开发人员身上。