为什么specflow的示例总是使用UI

Question

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

"它是一种测试,用户的规范用于从业务中生成有价值的语言"

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

我理解这个概念是错误的

Answer 1

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

在这里,您可以读到Dan希望将焦点从测试细节转移到描述行为.当然,这可以(并且肯定已经)在很多方面解释:).所以,无论你在哪里,你都会得到一个自以为是的观点 - 这是我的.

使用基于Cucumber的工具(如SpecFlow)的想法是写下团队对语言和工具中的功能的共享理解,所有参与者都可以阅读和理解.通过写下有关如何使用该功能的几个场景或示例,可以完成此操作(在基于Cucumber的工具中).有些人通过例子称这种说法.

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

• 您可以在实现之前讨论该功能的行为
• 使用从外到内的方法,规范为您提供了很好的代码规范
• 随着时间的推移,规范将成为回归测试,用于验证系统的行为是否符合规定
• 该规范还通过旧的TDD承诺来实现,并成为系统的生动文档.通过查看该功能已通过的可执行规范,您可以轻松查看功能的当前状态

所以现在终于回答你的问题了(顺便提一句,这是我经常问自己和其他人的一个很好的问题).请原谅我改写它,我希望我抓住你的意图:

我的方案是否必须(或应该)针对UI运行？

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

但是为了充分利用您的规格,您应该考虑上面的(不确定的)列表.如果您不包含GUI(或数据库或服务等),那么您无法确定整个应用程序堆栈是否正常工作.因此,规范通常是端到端的.

这使得这些"测试"与你的单元测试非常不同(你想要快速闪电,模拟外部依赖,而不是访问数据库等).它们需要更长的时间来执行,所有这些都不应该在每次签到时运行,不要使用模拟等.

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

最后到上面的例子.所以我建议你一直到数据库端到端地运行你的UI规范; 但我建议用上面的技术术语描述UI(例如使用按钮,链接和文本框).当我在BDD Google Group上提出这个问题时,我得到了Elisabeth Keogh的一个很好的建议:

不要描述UI.相反,请描述您尝试使用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人的"抨击".但是,嘿,这是我的两分钱:)