如何用小黄瓜风格描述一个简单的过程?

use*_*uck 2 bdd agile scrum user-stories gherkin

假设我正在设计一些SaaS服务.我需要一个允许用户创建网站的功能.用户可以在管理面板中为每个站点进行特殊设置(例如,小部件的设计),并获得安装服务的唯一代码到他自己的站点.

用户故事可能是:

作为一个已登录的用户,我想在管理面板中添加新网站,以便我可以单独配置每个小部件实例,并可以为我自己的网站获取安装小部件的唯一代码.

形成

但是,如果我尝试用BDD或GWT(给予时)或小黄瓜风格来描述这个功能,我将面临一些麻烦.我从下一个描述开始:

GIVEN我已登录管理面板而我正在"网站"页面上

当我点击"添加网站"按钮

然后出现弹出窗口"添加站点"

正如您在上面的实现中所见,假设站点添加将在弹出窗口中(例如,它对于UX非常重要).弹出窗口包含站点URL输入字段,带语言的下拉控件以及"添加"和"取消"按钮.

我们得到了一个奇怪的场景,它负责弹出开启.这是对的吗?我如何命名这个场景("添加网站的表格开头"??)?此场景也只有一种情况(当我点击 - 弹出打开).也许根本不需要这种情况?我糊涂了...

在这种情况下,我们需要在描述时创建另一个场景:

GIVEN打开"添加网站"弹出窗体

当我填写"站点URL"字段并单击"添加"按钮

那么新网站将在系统中创建,我将转移到我自己的网站列表

您如何看待,我需要在何处应用业务规则,例如:1)创建新网站时,必须生成唯一代码,并且包含最少8个字符,包括数字和字母符号.2)检查不适用于站点URL输入字段,用户可以输入西里尔符号3)等?

我有很多额外的问题,希望社区帮助!

Mar*_*nez 6

BDD的目的是尽可能远离实现细节.此方案有多个实现细节:

GIVEN I'm logged into admin panel AND I'm on "Sites" page
WHEN I click "Add site" button
THEN Pop-up window "Add site" come up
Run Code Online (Sandbox Code Playgroud)
  • 如果"站点"页面变为"令人敬畏的站点"页面或被删除,会发生什么?
  • 如果"添加网站"不再是按钮会怎样?
  • 如果它不是弹出窗口而是重定向发生会发生什么
  • 之后发生了什么?价值仅仅是显示弹出窗口吗?我猜不会...

对于这个具体的例子,更好的方法是:

GIVEN I'm an authorised administrator
WHEN I enter all the required information for a new site and save it
THEN I should see that site in my own sites list
Run Code Online (Sandbox Code Playgroud)

在这种情况下,如果您的实施发生变化,您只需更改步骤定义,就不必更改小黄瓜.不要忘记那些测试应该解释系统的行为,而不是它的实现方式.

在我看来,你所拥有的其他问题与单元测试更相关:

  1. 创建新网站时,必须生成一个唯一的代码,包含至少8个字符,包括数字和字母符号=>我会在课程级别进行,除非客户明确要求,否则gherkin不合适,那么条件是"然后为该站点生成具有所需特征的代码",您必须在词汇表中定义客户可以阅读和理解的"必需特征".

  2. 检查不适用于站点URL输入字段,用户可以再次输入西里尔符号=>,将其放在类级别与1.相同,除非客户希望能够阅读有关它的内容,它应该是在单位一级.

我希望能回答你的问题.如果你想更好地了解如何编写更好的小黄瓜功能,我推荐Dan North的这篇文章.

编辑11/13/14

根据您的意见,我建议我们退后一步,描述一种处理您案例中的要求的方法.我必须告诉你,我不是BDD专家,我只是分享我自己的个人经验,有关这个主题的更多信息,我建议你联系BDD KickstartCucumber.pro背后的人,你会发现在线BDD课程.他们将能够为您提供大量信息和书籍供您阅读.

话虽如此,让我们深入探讨这个话题.

你得到的第一件事是一系列功能或故事,如果你按照迈克科恩的故事模板看起来像:

As a <type of user> I want <to do something> in order to <serve a business purpose>
Run Code Online (Sandbox Code Playgroud)

我个人希望首先考虑业务目的,以确保我们不会在讨论中跳过它.您可能也不会遵循该模板,这很好,但请记住,确保您与客户列出的功能具有业务目的是一个好主意.如果某个功能背后没有商业价值,那么无论如何都要做到这一点......

所以你有一个如上所述的功能/故事列表.现在,对于这些功能中的每一个,都有不同的情况或场景,这就是Dan在他的文章中描述的内容.这是引入Given-When-Then的地方.

Scenario: Title
Given <some context>
When <there is an event>
Then <something happens>
Run Code Online (Sandbox Code Playgroud)

这些场景中的每一个都是关于此特定功能在不同上下文中的行为的示例.它们是特定功能的不同验收标准,客户将其描述为系统的预期行为.他们应该不了解任何实施细节.所以像:

Given I am on page "First page"
When I click "Hello world"
Then I should see "You clicked hello world"
Run Code Online (Sandbox Code Playgroud)

由于此编辑之前描述的原因是错误的.

我们假设以下功能:

In order to save time when answering clients requests, as a webmaster, 
I want to be able to manage the list of websites I am responsible for
Run Code Online (Sandbox Code Playgroud)

这个故事的场景是:

Scenario 1: Show a list of websites
GIVEN I am an authorised administrator
AND I am managing several websites
THEN I should see a list of all the sites I manage

Scenario 2: Add website to list
GIVEN I am an authorised administrator
WHEN I enter all the required information for a new site and save it
THEN I should see that site in my own sites list

Scenario 3: Edit website from list
GIVEN I am an authorised administrator
WHEN I edit the site informations
THEN I the changes should be visible in my sites list

...
Run Code Online (Sandbox Code Playgroud)

现在如果你想进入数据验证,例如"网站应该有一个标题".对我来说,有两种不同的方法来解决这个问题.您可以从用户的角度使用全栈测试或测试来测试,在对象级别进行一些验证.

我们假设以下场景:

Scenario: New site has no title
GIVEN I'm an authorised administrator
WHEN I forget to fill in the title for a new site and save it
THEN I should be warned the site is not valid
Run Code Online (Sandbox Code Playgroud)

您可以使用黄瓜或specflow从UX运行此方案,因此使用某种基于浏览的代理来测试您的应用程序.这通常很慢,因为它击中整个系统并模拟真实用户.这是一个选择,但我不认为这是最好的.IMO并不是所有的测试都应该针对用户体验进行操作,并且有太多的Gherkin功能可能会让人难以维持,这就是为什么我更喜欢专注于拥有快乐或关键的路径(通常我会问自己,钱来自哪里)测试完整 - 搁置并将其余部分放在较低的水平.

如果您愿意,您仍然可以使用Gherkin进行这些单元测试.但这不是强制性的.您只需要一种方法向您的客户展示您实际上对所有这些特定格式控件和验证检查进行测试.

这并不意味着你不再使用BDD,如果你是rubyist,或者你使用的任何其他测试框架,你仍然可以在rspec中使用当时给定的模式.

希望澄清这一切,让我知道是否有任何令人困惑的部分......