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