测试驱动开发是一种测试优先的软件开发方法，这意味着它需要先编写测试代码，然后再编写将要测试的实际代码。用肯特·贝克的话来说：
这里的风格是编写几行代码，然后编写应该运行的测试，或者甚至更好的做法是编写将无法运行的测试，然后编写将使其运行的代码。
在弄清楚如何编写一小段代码之后，现在，我们不仅要进行编码，还希望获得即时反馈并练习“一点点编写代码，一点点测试，一点点代码，一点点测试”。因此，我们立即为其编写了一个测试。
因此，TDD是程序员用来产生有效代码的低级技术方法。
行为驱动开发是一种基于TDD创建的方法，但后来演变为一个过程，该过程不仅涉及程序员和测试人员，而且涉及整个团队以及所有重要的技术和非技术利益相关者。BDD从TDD不能很好回答的几个简单问题开始：我应该编写多少测试？我应该实际测试什么？我不应该测试什么？实际上，我编写的哪些测试对业务或产品的整体质量很重要，而哪些只是我的过度设计？
如您所见，此类问题需要技术与业务之间的协作。业务利益相关者和领域专家通常可以告诉工程师什么样的测试听起来很有用，但前提是这些测试是涉及重要业务方面的高级测试。BDD称这类类似业务的测试为“示例”，如“告诉我此功能应如何正确运行的示例”，并为诸如数据验证或测试API集成之类的低级技术检查保留了“测试”一词。重要的是，尽管测试只能由程序员和测试人员创建，但是示例可以由整个交付团队（由设计师，分析师等）收集和分析。
一句话，到目前为止，我发现的BDD的最佳定义之一是BDD的意思是“与领域专家进行对话，并使用示例来获得对所需行为的共同理解并发现未知数。” 发现部分非常重要。随着交付团队收集更多示例，他们开始越来越了解业务领域，因此他们减少了对他们必须处理的产品某些方面的不确定性。随着不确定性的降低，交付团队的创造力和自主权也会增加。例如，他们现在可以开始建议自己的示例，这些示例由于缺乏专业技术知识而使业务用户认为不可能。
现在，与业务和领域专家进行对话听起来很不错，但是我们都知道在实践中通常会如此。我以程序员的身份开始了技术之旅。作为程序员，我们被教导编写代码-算法，设计模式，抽象。或者，如果您是设计师，就会被教导设计-组织信息并创建漂亮的界面。但是，当我们获得入门级工作时，我们的雇主期望我们“为客户创造价值”。在这些客户中，例如可以是……一家银行。但是我几乎对银行一无所知-除了如何有效地减少我的帐户余额。因此，我必须以某种方式将对我的期望转换为代码...如果我想提供任何价值，就必须在银行业和我的技术专长之间架起一座桥梁。BDD帮助我在交付团队和领域专家之间的稳定沟通的稳定基础上架起了一座桥梁。
学到更多
如果您想了解有关BDD的更多信息，我写了一本书。“撰写出色的规范”探讨了分析需求的技巧，将帮助您学习如何构建出色的BDD流程并将示例用作该流程的核心部分。本书讨论了无处不在的语言，收集了示例，并从示例中创建了所谓的可执行规范（自动测试），这些技术可帮助BDD团队按时，按预算提供出色的软件。
如果您有兴趣购买“书写规范” ，可以使用促销代码39nicieja2 节省39％：）