“我是雅典最聪明的人，因为我知道我一无所知。” -苏格拉底470-399 BC
什么是BDD（对我而言）
1.对话
BDD是关于对话的
对话有助于我们了解我们正在尝试构建和识别应用程序行为的内容
对话有助于我们分享有关我们正在建设的知识
通过对话，我们有意发现正在构建的行为，并消除了一些一阶的无知
等等，这不是真实的...啊，好吧，这是个玩笑:-)
BDD使用连续反馈进行有意发现
该发现有助于减少未知因素并交付重要的软件
2.记录应用程序的行为
BDD场景（或测试）有助于记录我们正在构建的应用程序的行为，因为它们记录了对话的结果
3.工具
有许多工具可以使方案的执行自动化。
4.测试
BDD通过对话测试假设，不存在其他关系。
我的结论
“ BDD是关于对话和协作以生成重要的软件”
这意味着：
对话产生了重要的软件
和
“在任何有意义的地方，通过场景描述业务语言中的行为并将其自动化将有助于您快速反馈并随着应用程序的增长对其进行维护。”
这意味着：
使用方案和良好的工程实践可以更有效
如果您不进行第1点（对话），则可以根据需要生成任意数量的场景，在比Google更大的服务器场中自动运行并连续运行它们，但是您没有太大的价值，而我谦虚地认为您没有做BDD。
Liz Kheogh的贡献极大地影响了BDD的发展，他这样简单地说：
BDD不是什么（对我来说）
我开始使用BDD的团队经常遇到的一个问题是谬误的出现，团队将BDD试图解决的问题与其他问题（例如工具，人工制品和测试）混为一谈。
我马上要清理干净，对此已经有很长一段时间了，我已经在自己的皮肤上学会了如何混淆概念是非常危险的。 请参阅下面的一些经验教训。
#Fallacy＃1：BDD是测试和自动化
这是一个非常普遍的问题。 它通常起源于某人（通常是测试人员）听到或阅读有关BDD的内容并开始使用Gherkin和BDD场景样式编写其测试时。 这通常是度蜜月的时期，在此期间可以获得好处，因为现在测试是用商务语言编写的，因此每个人都可以理解/理解。 这似乎有助于交流，但从长远来看，这实际上会使情况变得更糟，因为测试人员和开发人员开始通过以Gherkin编写的方案进行交流并停止交谈。 很多年前，我个人已经做到了。 举起手来，我搞砸了我的团队沟通严重！
在某些情况下，会决定使用BDD方案来代替自动化测试。 这使应该为开发某种行为（BDD）而编写的方案和为测试应用程序而编写的方案产生了混淆。 使用所有有边界的，无效的，特殊的开发场景并不是最佳选择，我们不是在寻找错误，而是根据行为来构建应用程序。
测试人员经常会推动通过UI自动化场景，并在端到端的完全集成环境中运行。 这通常会创建一个缓慢且不可预测的大型自动化套件，该套件既不适用于BDD快速反馈循环和发现，也不适合端到端集成测试。
在将BDD与测试相结合时，我们会造成不必要的混乱，并且最终导致的结果既不是回归测试也不是BDD场景，并且无法用于其原始目的（重要的软件开发）。
您要避免所有这些问题吗？ 将BDD与测试分开。 它们是2个完全不同的问题的2个解决方案。 对每个域使用适当的工具。 生活快乐。
#Fallacy＃2：BDD场景是一种交流工具
在一些商店中，我看到听到或读过BDD的业务分析人员和产品所有者决定将他们的需求正式化为BDD方案。 我已经看到这种方法，这是由接受BDD培训的一些人建议的，但这是灾难的根源。 BDD最重要的部分将被完全忽略，PO将在BDD场景中优雅地形式化他的假设。 一旦开发人员获得了BDD方案，她将把采购订单的假设传递到优雅的代码中。
对于测试的性质不能模棱两可，如果以测试形式定义要求，则无需提问或交谈。 这被某些人挥霍为一个巨大的优势，相反，它是故意发现的去世和假设驱动发展（ * ）的诞生。
您要避免这种情况吗？ 使用3个Amigos对话作为交流工具。 完成之后，您将拥有所有信息，可以将对话的发现形式化为BDD场景
#Fallacy＃3：我们使用黄瓜来做BDD
（随意用Jbehave，SpecFlow等代替Cucumber）
这是不合逻辑的 。
一些开发人员对整洁的工具感到非常兴奋，而我上面提到的那些工具非常酷。 在没有对话的情况下通过BDD场景使用工具和编写软件不同于进行BDD。 同样，在没有对话的情况下，不可避免地我们最终会进行假设驱动开发（ * ）。
一个类似的非谬误谬论：“我们使用Jira，我们很敏捷！”。
我期待着那天我对上面写的内容感到ham愧的那天，因为那天我会学到一些东西。
（ * ）假设驱动开发（ADD）=一个人以测试的形式单枪匹马地构建了一套关于应用程序行为的毫无疑问的假设。 通常，这种方法会在尝试性测试时失败很晚，有人质疑现在已内置在代码中的PO假设。
翻译自: https://www.javacodegeeks.com/2015/04/bdd-is-bdd-is-not.html