我一直在建议我的工作场所通过以场景格式编写高级规范来实现行为驱动开发，并且可以想象为它编写测试。
我确实知道针对可测试规范的工作往往是increase developer productivity。我已经可以想到几个例子，我们自己的项目就是这种情况。
然而，很难向企业证明这一点的价值。
这是因为我们已经有一个联合应用程序开发（JAD）流程，开发人员，管理人员，用户体验和测试人员都聚在一起就一组共同的需求达成一致。
因此，他们问，开发人员为什么要反对测试人员创建的测试用例？这些是用于验证的，并且基于UX团队创建的更高级别的规范，开发人员目前正在这些规范中工作。
他们说，这对开发人员来说已经足够了，而且无需改变规范的编写方式。
他们似乎有一点意义。
BDD / TDD的实际好处是什么，如果您已经有一个测试团队的测试用例与当前给予开发人员的更高级别的规范完全兼容？
答案 0 :(得分：3)
如果你想让他们相信这会有所帮助，你需要做的主要事情就是找出一个可以解决的问题。
您认为这会改善您的情况会发生什么？
BDD的主要好处是改善利益相关者和开发者之间的沟通。
如果您生成的代码未通过这些验证测试，那么开发人员就会明白您的规范与测试人员不同，这意味着规范缺乏明确性，BDD肯定能改善这种情况。
作为开发人员，您还可以使用该流程的一部分，而无需更改整个团队的流程。如果您专注于单元测试级别并进行传统的测试驱动开发，那么这可能会提高您的工作效率。
答案 1 :(得分：2)
这是一个很好的问题，实际上它是BDD的“底线”问题。 TDD或编写单元测试的主要挑战之一是开发人员似乎永远不会从事大局和业务视角。编写规范和生成单元测试以测试实际“业务”场景的练习有助于开发超越其“工艺”并掌握业务视角。查看这篇文章了解更多详情，
http://codingcraft.wordpress.com/2011/11/12/bdd-get-your-tdd-right/
答案 2 :(得分：1)
以最轻的形式思考BDD可能会有所帮助;作为围绕特定场景的讨论。
你有你的用例。你有你的要求。现在你要验证你对这些有了很好的理解。所以有人 - 可能是开发人员，也许是测试人员 - 说，“好的。只是为了验证我的理解......鉴于我们从＆lt; this＆gt;开始，当用户执行＆lt; this＆gt;然后＆lt; this＆gt;应该发生那是对的吗？“
测试人员会说：“是的，那是对的。”
然后，UX或分析师说，“好吧，除非＆lt;这个其他背景存在＆gt;”这是正确的。
通过围绕这些场景进行讨论，确保每个人都有共同理解所需的时间会大大减少。我们通常会忽略明显的情景，并专注于边缘情况;在新的域名术语，部门之间存在差异的概念，与遗留系统的困难交互。
开发人员并没有真正处理测试用例。它们的工作原理与要求和验收标准完全相同。测试用例只是他们可能期望的一种例子;用户可以从中获益或传递系统价值的场景。自动执行这些测试用例非常有用，因为测试工作量大致与代码库的大小成比例增加。
BDD在需求或领域存在很大不确定性的项目中效果最好，人们的理解差别很大。如果您的项目已经运作，那么请坚持下去。也许你可以看看提出想法与实现它们之间的最大差距在哪里，如果BDD在这个领域帮助你，请使用它;否则选择其他东西。无论如何，你所做的事情听起来与BDD过程非常相似。
答案 3 :(得分：0)
我刚刚遇到这个问题并认为我会考虑，因为这真的是一个非常有趣的问题。
只有当整个团队认为方法被破坏，并且最终结果是失败的项目时，方法才会被打破。
如果现有系统运行良好，那么你真的需要问自己，“我可以像这样工作，即使我可能更喜欢BDD / TDD吗？”。如果你的答案是否定的，并且你觉得你可能对任何其他系统工作不满意，那么也许这表明你的职业生涯需要转移到其他地方。如果是，那么请接受系统。
实际上，如果是我，我会接受一个新系统。首先，如果你有机会熟悉它，那么你就可以有时间对相对的利弊做出更明智的判断，并且根据这些知识，你可以建议在以后的日子里做出改进。是必要的。
在一天结束时，方法论的效果与最终结果一样好。工作软件，以及所有利益相关者的满意度。
： - ）