我的理解是：
BDD是评估软件行为需求的过程，然后编写验证测试，以此为基础构建代码。您可以使用TDD方法编写代码，通过编写方法的单元测试并围绕单元测试（代码，测试，重构）构建类。编写代码时，对其进行测试以确定其是否满足原始验收测试。
任何有经验的人都可以对我的解释进行全面评论，并使用这些敏捷原则来介绍一个简单的应用程序吗？我看到在不同的出版物中有大量关于BDD和TDD的文本，但我正在研究这两个过程如何在现实世界的发展中相互补充。
答案 0 :(得分：4)
尝试将它们视为示例，而不是测试。
对于整个应用程序，我们提供了一个用户如何使用该应用程序的示例。该示例是一个特定的行为实例，用于说明该行为。因此，例如，我们可以说，直到申请允许退款。使用它的直到操作员将熟悉弗雷德带回微波炉退款的情景：
鉴于Fred以100美元的价格买了一台微波炉 当他带回微波炉退款时 然后他应该将100美元退还给他的信用卡。
现在很容易想到其他场景;例如，弗雷德获得折扣并且只能获得90美元的折扣，或弗雷德自己打破微波炉的那个，我们拒绝退款等等。
当我们真正开始编写直到软件时，我们将代码分解成小块;类，函数，模块等我们可以描述一段代码的行为，并提供一个示例。因此，举例来说，我们可能会说退款计算器应考虑折扣。这只是退款方案的一小部分。我们有一个班级RefundCalculator和一个单元测试，其中的方法是shouldTakeDiscountsIntoAccount。
我们可能会在评论中提供示例的步骤，例如：
// 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.
...
然后我们填写代码将其转换为单元测试，并编写使其通过的代码。
通常＆＃34; BDD＆＃34;是指描述整个应用程序的场景，但这些想法实际上是在单元级别开始的，原则是相同的。唯一的区别是一个是使用应用程序的用户的示例，另一个是使用另一个类（或函数，或者你有什么）的类的示例。因此，应用程序外部的BDD就像ATDD（接受测试驱动开发），类的BDD就像TDD。希望这有助于您了解这些概念是如何结合在一起的。
唯一的区别是我们摆脱了＆＃34; test＆＃34;这个词，因为我们发现让人们更容易问一个例子而不是测试，这有助于让人们思考他们是否理解问题而不是考虑如何测试解决方案。
This answer on＆＃34; top down＆＃34; （或从外到内）与＃34;自下而上＆＃34;也可以帮到你。
答案 1 :(得分：1)
您的摘要基本上是正确的。标签可能会产生误导：称他们所做的'BDD'的人会写出验收测试和单元测试，那些称他们做'TDD'的人会编写验收测试和单元测试。对我来说，两者之间的区别是无关紧要的。您将阅读许多人对这一基本过程的不同风格的体验。尝试在您的情况下似乎有意义的方法，并始终准备根据哪些有效并且不适合您进行调整 - 这是敏捷的本质。
答案 2 :(得分：1)
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?