我的理解是这样的：
BDD 是评估软件需要如何运行，然后编写验收测试作为代码基础的过程。您将使用 TDD 方法编写代码，为方法编写单元测试并围绕单元测试（代码、测试、重构）构建类。编写代码时，您对其进行测试以查看是否满足原始验收测试。
任何有经验的人都可以对我的解释发表评论，并介绍一个使用这些敏捷原则的简单应用程序吗？我在不同的出版物中看到了大量关于 BDD 和 TDD 的文字，但我正在研究这两个过程如何在现实世界的开发中相互补充。
【问题讨论】：
您的总结基本上是正确的。这些标签可能会产生误导：将他们所做的事情称为“BDD”的人将编写验收测试和单元测试，将他们的工作称为“TDD”的人将编写验收测试和单元测试。对我来说，两者之间的区别是无稽之谈。您将阅读许多人对这个基本过程的不同风格的经验。尝试在您的情况下似乎有意义的方法，并随时准备根据对您有效和无效的方法进行调整——这就是敏捷的精髓。
【讨论】：
尝试将它们视为示例，而不是测试。
对于整个应用程序，我们提供了一个用户如何使用该应用程序的示例。该示例是说明该行为的特定行为实例。因此，例如，我们可以说收款应用程序允许退款。使用该收款机的收款机操作员将熟悉 Fred 带回微波炉进行退款的场景：
鉴于 Fred 花了 100 美元买了一台微波炉
当他把微波炉拿回来退款时
然后他应该得到 100 美元的退款到他的信用卡。
现在也很容易想到其他场景；例如，Fred 打折后只退了 90 美元，或者 Fred 自己弄坏了微波炉，我们拒绝了他的退款，等等。
当我们真正开始编写 till 软件时，我们会将代码分解成小块；类、函数、模块等。我们可以描述一段代码的行为，并提供一个例子。因此，例如，我们可能会说退款计算器应该考虑折扣。这只是退款场景的一小部分。我们有一个类 RefundCalculator 和一个带有 shouldTakeDiscountsIntoAccount 方法的单元测试。
我们可以将示例中的步骤放在 cmets 中，例如：
// Given a microwave was sold at 10% discount for $100
...
// When we calculate the refund due
...
// Then the calculator should tell us it's $90.
...
然后我们填写代码把这个变成单元测试，写代码让它通过。
通常“BDD”是指描述整个应用程序的场景，但思想实际上是从单元级别开始的，原理是一样的。唯一的区别是一个是用户使用应用程序的示例，另一个是使用另一个类（或函数，或者你有什么）的类的示例。因此，应用程序外部的 BDD 类似于 ATDD（验收测试驱动开发），而类的 BDD 类似于 TDD。希望这有助于您了解这些概念是如何结合在一起的。
唯一的区别是我们去掉了“测试”这个词，因为我们发现向人们询问示例比测试更容易，它有助于让人们思考他们是否理解问题，而不是思考问题如何测试解决方案。
This answer“自上而下”（或由外而内）与“自下而上”也可能对您有所帮助。
【讨论】：
BDD 故事有两种方法，imperative and declarative。开发人员可能会发现命令式故事更容易编写，尤其是在用于编写单元测试脚本时。
但是，当从敏捷测试优先/测试驱动开发方法处理此问题时，声明性方法会导致 BDD 叙述为cogent with the development stories。这是因为 BDD 叙述继续反映 domain language of the business 而不是编程领域。
How do you capture requirements with declarative acceptance tests?
【讨论】：