Bre*_*den 5 bdd acceptance-testing cucumber calabash
背景
我正在努力帮助我的团队组织一个新的移动应用项目.我们选择遵循BDD(参见BDD定义)以捕获简单的英语要求,这些要求构成了利益相关者和开发者之间针对每个用户故事的合同.
我们使用验收测试来记录每个用户故事的要求.在sprint计划之前编写验收测试.开发人员在sprint计划期间改进并添加测试.
我们将Acceptance Criteria定义为规则列表(例如:输入验证,默认值等),将Acceptance Tests定义为Cucumber场景列表.我们计划使用Calabash进行移动测试.
我认为验收标准/测试更灵活,因此更好地解决了更正式的需求文档.
我觉得我找到了一个有效的解决方案,但我想了解其他人是如何收集要求和编写验收测试的.
问题
在Cucumber社区中,有必要与声明性测试步骤进行辩论.我倾向于强制要求,因为开发人员必须知道可交付用户故事的样子.
我不认为UI耦合又称脆性测试是一个问题.有一些方法可以将UI与测试分离(例如:页面对象).我也不认为有详细的步骤使非技术利益相关者难以理解(除非他们不知道如何使用网络浏览器或移动设备,但这是一个单独的问题).
我可能会挪用" 验收测试 "一词.在我的使用中,验收测试与单元测试的范围不同.我将验收测试视为高级集成测试.
这个例子
势在必行的测试
声明测试
这两者都可以覆盖相同的功能而后者更短,但它没有说我是否可以使用用户名,电子邮件或facebook/twitter/google/etc帐户登录.仅仅实际编写解决方案是不够的
问题
如何使用声明性步骤捕获要素？
写的很好的问题！
您如何通过声明性步骤捕获功能的需求？
功能的要求记录在步骤定义中。
因此，在您的命令式示例中：
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
同样，满足验收标准的实现此场景的步骤可以在基础步骤定义中实现。
采用这种声明式方法意味着您会失去功能的（强制性）要求（即需要执行哪些确切步骤），从而使业务更难仅通过读取功能文件来准确了解这些场景正在做什么。但是，您获得的是测试变得不那么脆弱，因为完成任务的具体步骤记录在步骤定义中，并且该步骤定义可以在许多功能之间共享。
在我的公司，我们也遇到了同样的问题，我们发现在某些情况下，最好使用命令式而不是声明式，反之亦然。例如，在您的情况下，构成“Given I have a valid account”的步骤可能用于许多功能，因此使其具有声明性是合理的。但是，如果您有一个输入许多不同字符串值的功能，那么在这种情况下，最好是命令式地编写它们。
从 SO 社区看到这个问题的其他答案会很有趣。