specflow - 为什么specflow的例子总是使用UI

Question

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

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

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

我对这个概念的理解错了吗

Answer 1

BDD(行为驱动设计)是 Dan North 创造的术语，理解其意图的最佳来源是 this excellent blog post

在这里您可以看到 Dan 希望将焦点从测试细节转移到描述行为。当然，这可以(并且肯定已经)以多种方式解释:)。因此，无论你向何处寻求帮助，你都会得到固执己见的观点——这是我的观点。

Cucumber 的想法基于模型的工具，例如 SpecFlow，是用一种所有参与者都可以阅读和理解的语言和工具写下团队对某个功能的共同理解。这是通过写下几个关于如何使用该功能的场景或示例来完成的(同样是在基于 Cucumber 的工具中)。一些people通过示例调用此规范。

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

• 您可以在实现该功能之前讨论该功能的行为
• 该规范为您提供了一个很好的编码规范，使用outside-in approach
• 随着时间的推移，规范会变成回归测试，以验证系统的行为是否符合规定
• 该规范还兑现了旧的 TDD promise ，并成为系统的动态文档。通过查看功能已通过的可执行规范，您可以轻松了解该功能的当前状态

现在终于回答你的问题了(顺便说一下，这是一个很好的问题，我经常问自己和其他人)。请原谅我重新措辞，希望我能理解您的意图:

Do my scenarios have to (or should they) be run against the UI?

您当然不必针对 UI 运行场景 - BDD 的原理和工具在任何层中都可以很好地针对您的域。

但是为了充分利用您的规范，您应该考虑我上面的(非决定性的)列表。如果您不包含 GUI(或数据库或服务等)，那么您无法确保整个应用程序堆栈能够正常工作。因此，规范常常是端到端运行的。

这使得这些“测试”与您的单元测试非常不同(您希望单元测试快如闪电，模拟外部依赖项，而不是访问数据库等)。它们需要更长的时间来执行，所有这些都不应该在每次 checkin 时运行，不要使用模拟等。

通常，您从场景的一个步骤开始并作为行为的驱动程序，然后使用普通的 TDD 来驱动系统内部的细节。这是由外向内的编程。

最后是上面的例子。因此，我建议您针对 UI 端到端运行您的规范，一直到数据库；但我建议使用上述技术术语来描述 UI(例如使用按钮、链接和文本框)。当我在 BDD Google Group 上问这个问题时，我从 Elisabeth Keogh 那里得到了一个很好的提示:

Don't describe the UI. Describe instead what you're trying to achieve with the 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 人士的“抨击”。但是嘿，这是我的两分钱:)