4

我是 BDD 的新手，试图理解它。我对 BDD 的理解是 ..

“这是一种使用用户规范从业务中生成通用语言的测试”

但是这些例子我只能看到 UI 的例子..就像按下按钮时..当用户输入文本时......这不会形成我可以在我的代码中使用的语言..

我理解这个概念错了吗

4

2 回答 2

6

BDD（行为驱动设计）是 Dan North 创造的一个术语，了解他的意图的最佳来源是这篇优秀的博客文章

在这里，您可以读到 Dan 希望将注意力从测试细节转移到描述行为上。当然，这可以（并且肯定已经）以多种方式解释:)。所以无论你转向哪里，你都会得到一个固执己见的观点——这是我的观点。

使用基于Cucumber的工具（如 SpecFlow）的想法是写下团队对所有相关人员都能阅读和理解的语言和工具的功能的共同理解。这是通过写下几个关于如何使用该功能的场景或示例来完成的（同样在基于 Cucumber 的工具中）。有人将这个规范称为例子。

通过以这种方式使用示例来编写规范会带来一些好处：

  • 您可以在功能实施之前讨论该功能的行为
  • 规范为您提供了一个很好的规范，可以使用由外向内的方法进行编码
  • 随着时间的推移，规范变为回归测试，验证系统是否按规定运行
  • 该规范还体现了旧的 TDD 承诺，并成为系统的活文档。通过查看功能已通过的可执行规范，您可以轻松了解功能的当前状态

所以现在终于到了你的问题（顺便说一句，这是我经常问自己和其他人的一个很好的问题）。请原谅我重新措辞，我希望我能抓住你的意图：

我的场景是否必须（或应该）针对 UI 运行？

您当然不必针对 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 人员的一些“抨击”做好准备。但是，嘿，这是我的两分钱:)

于 2011-04-01T10:57:50.420 回答
0

我对 BDD 和 Specflow 还是很陌生。我们一直在使用它来建立行为并编写控制器代码，进而驱动视图。我面前没有代码示例，但我会尝试找到稍后发布的内容。干杯!

编辑- 顺便说一句，如果你正在寻找一本关于使用 Cucumber 的好书（它使用与 Specflow - Gherkin 相同的语言？我仍然把所有的部分都弄清楚了），我强烈推荐Pragmatic Programmers的 The RSpec Book。代码是基于 Ruby 的，但是有一些关于项目定义和运行的更高级别的章节。很值这个价。

于 2011-03-31T12:18:50.440 回答