背景
我正在努力帮助我的团队组织一个新的移动应用项目。我们选择遵循BDD（另请参阅BDD definition）以获取简单的英语要求，这些要求构成了利益相关方和开发人员之间针对每个用户故事的合同。
我们使用验收测试来记录每个用户故事的要求。在sprint计划之前编写验收测试。开发人员在sprint计划期间优化并添加测试。
我们将 Acceptance Criteria 定义为规则列表（例如：输入验证，默认值等）和 Acceptance Tests 作为Cucumber场景列表。我们计划使用Calabash进行移动测试。
我认为验收标准/测试更灵活，因此更适合更正式的需求文档。
我觉得我找到了一个有效的解决方案，但我想了解其他人是如何收集要求和编写验收测试的。
问题
Cucumber社区对imperative vs declarative测试步骤进行了辩论。我倾向于强制要求，因为开发人员必须知道可交付的用户故事是什么样的。
我不觉得UI耦合又称脆性测试是一个问题。有一些方法可以将UI与测试分离（例如：page objects）。我也不认为有详细的步骤会让非技术性的利益相关者难以理解（除非他们不知道如何使用网络浏览器或移动设备，但这是一个单独的问题）。
我可能会挪用“Acceptance Test”一词。在我的使用中，验收测试与单元测试的范围不同。我将验收测试视为高级integration test。
示例
命令测试
声明测试
这两者都可以涵盖相同的功能而后者更短，但它没有说我是否可以使用用户名，电子邮件或facebook / twitter / google / etc帐户登录。实际编写解决方案仅仅是不够的
问题
如何使用声明性步骤捕获要素？
答案 0 :(得分：4)
写得很好的问题！
如何使用声明性捕获要素 步骤是什么？
要素的要求记录在步骤定义中。
因此，在您的命令性示例中：
When I enter "email@domain.com" in "email"
And I enter "password1" in "password"
And I tap "login"
这可以通过将其重写为：
来声明Given I login using valid credentials
然后可以在此场景声明的步骤定义中实现导航到有效帐户的步骤（即，实现定义“有效”含义的接受标准）。这同样适用于相反的情况，即
Given I login using invalid credentials
同样，实现此方案的满足验收标准的步骤可以在基础步骤定义中实现。
采用这种声明式方法意味着您失去了该功能的（命令性）要求（即需要执行的确切步骤），这使得企业更难以完全看到 这些方案是什么只是阅读功能文件。但是，您获得的是测试变得不那么脆弱，因为实现任务的具体步骤记录在步骤定义中，并且此步骤定义可以在许多功能之间共享。
在我的公司，我们也有同样的担忧，我们发现在某些情况下最好使用命令而不是声明，反之亦然。例如，在您的情况下，组成“给定我有一个有效帐户”的步骤可用于许多功能，因此使其声明是合理的。但是，如果你有一个输入许多不同字符串值的功能，那么在这种情况下最好强制写出它们。
从SO社区看到这个问题的其他答案将会非常有趣。
答案 1 :(得分：1)
我最近去过一家商店/网上购买洗衣机和洗碗机。我想要的只是买一个用水少，洗得快的。但我遇到的细节是压倒性的;例如RPM，内鼓厚度，KW中的总连接负载等。
从上面的简单例子看，势在必行的风格似乎很合适，但实际上它使阅读场景更难和更无聊。您可以通过阅读项目中的10个方案来体验它，在这个项目中，您不直接参与技术/日常工作。
鉴于使用黄瓜的目的之一是在项目中引入透明度，特别是非技术用户，声明式风格在使管理层积极参与方面要好得多。我在我的项目中看到了这一点。
这是一个虚构的故事。尝试以强制性的方式实施它，在几天后回来读它，你会发现它太无聊了。
Feature: Delivery
Free delivery is offered to customers who order two or more items
Scenario Outline: Calculate postage for delivery
Given I am signed-in
When I "<order>" items
Then postage should be "<postage>"
Examples:
| order | postage |
| 1 | 0.99 |
| 2 | 0 |
| 3 | 0 |
| 0 | ? |
您可能希望阅读的另一个链接How to implement UI testing without shooting yourself in the foot