BDD产品负责人的生活文档

Question

我们在团队中使用BDD已经一年多了。运行我们测试的作业以业务语言生成published report，任何人都可以阅读。

我们发现这些在我们的团队中非常有用，用于tests fail等，但是我们的业务似乎并不认为这些文档作为一个通信工具很有用。我不确定是GWT language还是我们报告的格式，还是普遍缺乏兴趣。

如果有人使用同样的方法，您是否发现业务发现这个活文档很有用？

如果是这样的话，你是怎么做到的？

任何分享的经验都是很棒的。

Answer 1

老实说，这听起来就像是分裂了BDD工具的问题。您要么拥有在测试运行期间生成规范的工具，要么就知道您的系统能够做什么。或者您有使用规范的工具，这样您就可以知道您的应用程序是如何与规范兼容的。

在第一种情况下，这意味着像mspec这样的工具被用来将代码转换成一个可读的规范，该规范可以返回给业务，这样他们就可以验证它。我的经历跟你的很像，他们不感兴趣。这只是他们可以避免的过程中的一种开销。

然而，在第二种情况下，我们抓住他们的时候，他们的参与程度要高得多。他们想要发展，所以他们得到了积极的利益，他们非常高兴地告诉我们，他们想要它。我发现现在是使用BDD规范的时候了。事实上，这样做有几个优点。

规范只需由企业审查一次。如果他们参与了对规范的更改，那么在每个测试周期中都可以将其视为正式的标准，如果我们满足了，我们就完成了，不需要让他们对其进行审查。

Answer 2

我参与了一个BDD框架的创建，在这个框架中，我们使用Calabash、J687和Thucydides创建了BDD框架，我们使用BDD和rest创建了报告，所有部分都是用Selenium - Java编写的。因此，所使用的框架工作是Selenium，编码语言是Java，采用单元测试框架TestNG。

我看到了你的问题，对于我们的情况，我们也向客户提交了第一稿，他通过我们的实施方式得到了他的印象。

所以我的问题是，你能不能分享一下你在项目中所遵循的一些反馈或故事模式。所以我可以帮你或者我们可以比较我们俩的代码。

此外，我们公司也有一些项目，客户需求通常采用Requirement.story模式，测试人员开始使用测试驱动开发( testers )来编写这个故事。它对我们有很大的帮助。但是的，我想知道从你的结束，到目前为止，我的经验，在BDD运行顺利。