我是BDD的新手试图理解它。我对BDD的理解是......
“这是一种测试，其中用户规范用于从业务中生成Ubquitious语言”
但是这些例子我只能看到UI的例子..就像当按下按钮时...当用户输入文本时...这不会形成我可以在我的代码中使用的语言.. < / p>
我理解这个概念是错误的
答案 0 :(得分：6)
BDD（行为驱动设计）是Dan North创造的一个术语，了解他的意图的最佳来源是this excellent blog post
在这里，您可以阅读Dan希望将重点从测试详细信息转移到描述行为。当然，这可以（并且肯定已经）在很多方面解释:)。所以，无论你在哪里，你都会得到一个自以为是的观点 - 这是我的。
基于Cucumber的工具（如SpecFlow）的想法是写下团队对所有相关人员可以阅读和理解的语言和工具中的功能的共享理解。通过写下有关如何使用该功能的几个场景或示例，可以完成此操作（在基于Cucumber的工具中）。有些people通过示例来称呼此规范。
通过以这种方式使用示例编写规范可以带来一些好处：
所以现在终于回答你的问题了（顺便提一下，这个问题我常常问过自己和其他人）。请原谅我改写它，我希望我抓住你的意图：
我的方案是否必须（或者应该）针对UI运行？
您确定无需针对用户界面运行方案 - BDD的原则和工具在任何层中都可以很好地对抗您的域。
但为了充分利用您的规格，您应该考虑上面的（不确定的）清单。如果您不包含GUI（或数据库或服务等），那么您无法确定整个应用程序堆栈是否正常工作。因此，规范通常是端到端的。
这使得这些“测试”与你的单元测试非常不同（你想要快速闪电，模拟外部依赖，不要攻击数据库等）。他们需要更长的时间来执行，所有这些都不应该在每次办理登机手续时运行，不要使用模拟等。
通常，您从一个场景的步骤开始，作为行为的驱动程序，然后使用普通的TDD来驱逐系统内部的细节。这是编程外的。
最后到上面的例子。所以我建议你一直到数据库端到端地运行你的UI规范;但我建议用上面的技术术语描述UI（例如使用按钮，链接和文本框）。当我在BDD Google Group上提出这个问题时，我得到了Elisabeth Keogh的一个很好的提示：
不要描述用户界面。请描述您尝试使用UI实现的目标。
因此，要描述登录功能，请不要写：
Scenario: Login (describing the UI)
Given I am on the Login-page
When I enter 'AUser' in the textbox 'UserName'
And I enter 'APassword' in the textbox 'Password'
And I click the 'Login' button
Then I should see the following text 'You are logged in'
而是写下这样的东西：
Scenario: Login (describing what we want to achieve)
Given I am not logged in
When I log in using 'AUser' and 'APassword'
Then I should be logged in
这使得完成此操作（单击按钮，填写表单，检查消息等）的复杂性在您在代码中编写的步骤定义中完成。
我希望这很有帮助。此外，我正在为自己做一些可能来自其他更有经验的BDD人的“抨击”。但是，嘿，这是我的两分钱:)。
答案 1 :(得分：0)
我对BDD和Specflow也很陌生。我们一直在使用它来建立行为并对控制器进行编码，从而驱逐视图。我面前没有代码示例，但我会尝试稍后发布一些内容。干杯！
编辑 - 顺便说一句，如果你正在寻找一本关于使用Cucumber的好书（它使用与Specflow相同的语言 - Gherkin？我仍然可以直接获得所有部分），我可以强烈推荐Pragmatic Programmers的 RSpec Book 。代码是基于Ruby的，但是有一些关于项目定义和运行的更高级别的章节。物超所值。