我的理解是这样的：BDD和TDD，什么是正确的工作流程？
BDD是评估软件如何行为，然后编写验收测试的过程，以此为基础编写代码。您可以使用TDD方法编写代码，编写方法的单元测试并在单元测试（代码，测试，重构）周围构建您的类。在编写代码时，您会测试它是否符合原始验收测试。
任何人都可以对我的解释有全面的评论经验，并可以通过使用这些敏捷原则的简单应用程序漫步吗？我发现在单独的出版物中有很多关于BDD和TDD的文本，但我正在研究这两个过程如何在现实世界的发展中相互补充。
试着把它们当成例子而不是测试。
对于整个应用程序，我们想出了一个用户如何使用该应用程序的例子。该示例是一个说明该行为的特定行为实例。所以，举例来说，我们可能会说，直到申请允许退款。一直到运营商谁使用了，直到将熟悉弗雷德带回一台微波炉退款方案：
鉴于弗雷德买了一台微波炉$ 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.
...
然后我们填写的代码把它变成一个单元测试，写这使得它通过代码。
通常情况下，“BDD”是指描述整个应用程序的场景，但这些想法实际上是在单元层面开始的，原理是相同的。唯一的区别是一个是使用应用程序的用户的示例，另一个是使用另一个类（或函数，或您有什么）的类的示例。因此，BDD在应用程序的外部就像ATDD（Acceptance-Test-Driven Development），类的BDD就像TDD。希望这可以帮助您了解这些概念如何结合在一起。
唯一的区别是，我们摆脱了“测试”一词，因为我们发现它更容易让人们比测试的例子，它有助于保持人们思考他们是否理解这个问题，而不是思考关于如何测试解决方案。
This answer“自上而下”（或外部进入）与“自下而上”也可能对您有所帮助。
您的总结基本正确。这些标签可能会产生误导：调用他们做'BDD'的人将写入验收测试和单元测试，那些称他们做'TDD'的人会写验收测试和单元测试。对我而言，两者之间的区别是毫无意义的。你会阅读很多人对这个基本过程的不同口味的体验。尝试在您的情况下看起来有意义的方法，并始终准备根据哪些方法可行，哪些方面不适合您进行调整 - 这就是敏捷的本质。
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?
谢谢Mike。 – Alex
关于“测试”这个词有点太过分了。对于开发人员来说，这可能并不意味着很多，特别是如果我们习惯了TDD，但是如果您正在与商业人士交谈，这一点非常重要。 “你可以给我一个例子吗？”比“你能给我一个验收测试吗？”要容易得多吗？ – Lunivore
@Lunivore好点，我是一个小骑士。 –