首先，一些定义；
TDD是测试驱动开发，顾名思义，我们产生的测试驱动了我们的开发流程。通常与红绿重构周期一起描述。因此，在实践中，我们编写一个单元测试并失败，给我们一个红色状态，然后我们修复我们的应用程序代码直到我们通过测试，给我们一个绿色状态，最后我们重构我们的应用程序代码和测试代码，以便我们拥有良好的设计。良好的TDD通过将每个测试集中在我们想要测试的类中的单个方法上，并注入模拟依赖项，使我们测试最小可能量的代码，这导致测试套件中单个错误会导致单个失败。
BDD是行为驱动开发，其中行为是我们设计过程的驱动因素。当您遵循BDD流程时，您需要与人们合作，确定应用程序的功能和特点，并捕获它应该运行的一些场景示例。实际上，我们也可以将BDD视为一个周期，在这个周期中，我们收集应用程序应具备的新功能，验证应用程序是否适用于所有情况，可能重构我们的测试以使它们最有意义，然后重复整个过程。BDD测试通常需要许多类协作来生成单个业务功能，因此即使出现错误触发了单个失败，您仍然需要追踪大量代码以找到负责的代码。
在这一点上，您可以看到BDD的工作级别高于TDD，事实上我已经看到BDD外部周期成功地用于驱动一个TDD内部周期，例如：
定义新的业务功能
---> 添加场景和测试：BDD Red
| -> 添加单元测试：TDD Red
| | 添加应用程序代码：TDD Green
| -- 重构代码：TDD refactor
| 场景通过：BDD green
--- 重构功能和场景：BDD refactor
功能完成
Gojko Adzic在他的演讲TDD:Breaking the mould中更好地描述了这一点。
它在Web开发中实际上有什么用处？
BDD非常有用，因为它是一个用于收集需求的过程，并通过BDD工具自动确认您的代码库具有业务所需的所有功能。我发现BDD最适合使用多个类协作的集成样式测试，而不是专注于单个方法的单元测试。
您可以使用BDD构建应用程序逻辑，并可以使用它来测试大部分网站。我个人会避免测试UI，而是在代码后面工作，使用诸如“当用户搜索BDD”之类的语言，但有些人使用Selenium并编写关于单击和测试框的测试，“当用户在搜索文本框中输入BDD并单击搜索按钮”。
作为.NET中忙碌的Web开发人员，将时间花费在BDD和TDD上是否值得？
希望现在你能自己回答这个问题了。你需要决定引入BDD到你的流程中会得到多少好处。你的好处将根据团队规模和你选择的工具等因素而异。
我注意到你正在使用标记你的问题与nBehave一起使用的纯文本规范形式的BDD工具。这使你可以让BA团队处理纯文本场景并将它们提交回来（虽然不要全部交给他们，你需要一些技术输入来保持场景的一致性）。其他形式的工具，如mSpec，则是相反的方式，使用C#来描述场景，并生成纯文本作为构建过程的结果。个人使用SpecFlow，它具有nBehave的所有优点，但其测试可以通过nUnit运行器、resharper和你的构建服务器运行。但你可能想把你的集成测试与单元测试分开，并报告不同级别的覆盖率，例如。
最后，
尽管这些工具通常是专门为BDD项目开发的，但它们可以被看作是支持测试驱动开发的工具的专业形式。这些工具用于向BDD的普遍语言添加自动化，这是BDD的一个核心主题。
这意味着BDD工具的工作方式与我们现有的TDD工具类似，并且知道如何生成或理解Given When Then的BDD语法。如果想了解更多信息，建议阅读
https://github.com/cucumber/cucumber/wiki/Gherkin。
如果您想了解更多关于BDD作为一个过程的内容，Liz Keogh有很多非常好的资料，可以从这里开始
http://lizkeogh.com/behaviour-driven-development/。
（当我开始时，哎呀，这比我想象的要长得多）
