我已经为我们的Web应用程序编写了一个模态幻灯片,它为文档集合提供导航,并公开这些文档的各种元数据。
这是应用程序的一个大组件,具有深奥的要求,因此我认为其核心场景(作为验收标准给我的)既多样化又内部一致是合理的。
为避免针对我们众多场景进行新步骤的编写,我使用了一个帮助程序,该程序将可读性强的术语(例如“文档标题”)翻译成选择器。你可以参考这里了解更多。
但事实并非如此——我很难接受黄瓜试图将每种步骤定义模式应用于每个场景。如果这些测试要有任何价值,它们将变得更加数量众多,引入新的概念,并且不需要不断重写就能保持相关性。我希望能够限制我的步骤范围,防止它们干扰不是为其编写的功能,但我不知道该怎么做。以下概念解决方案值得考虑:
这是应用程序的一个大组件,具有深奥的要求,因此我认为其核心场景(作为验收标准给我的)既多样化又内部一致是合理的。
为避免针对我们众多场景进行新步骤的编写,我使用了一个帮助程序,该程序将可读性强的术语(例如“文档标题”)翻译成选择器。你可以参考这里了解更多。
module SelectorsHelper
def selector_for(term)
case term
# Lightbox / modal / fancybox
when 'lightbox'
'#fancybox-inner'
when 'close button'
'.document-viewer__tools__close'
除了以下几个通用的步骤定义,还有其他一些特定于 IT 技术的定义:
# Generic click action
When(/^I click (?:on )?(?:the |a )'(.*?)'?$/) do |element|
find(selector_for(element)).click
end
无论是像上面那样处理非常通用的概念,还是涉及到在一组特征中重复出现的模式等更具体的抽象概念,问题在于它们可能会对其他深奥的特征造成破坏,而这些特征可能有更具体的步骤来解析它们。我看过的每个Cucumber示例都有一个步骤定义文件,其文件名与特定特征文件存在过程关系,我的假设是,在这些情况下,该步骤定义文件只会被调用以解析与其相关的特征中的场景:
+ features
| + step_definitions
| | + global_steps.rb
| | + modal_steps.rb
| | + login_steps.rb
| + modal.feature
| + login.feature
但事实并非如此——我很难接受黄瓜试图将每种步骤定义模式应用于每个场景。如果这些测试要有任何价值,它们将变得更加数量众多,引入新的概念,并且不需要不断重写就能保持相关性。我希望能够限制我的步骤范围,防止它们干扰不是为其编写的功能,但我不知道该怎么做。以下概念解决方案值得考虑:
- 使用背景或场景
@tags
,仅为具有这些标签的场景调用步骤 - 将步骤定义嵌套在某种包装助手或元步骤定义中,该定义由错误的背景给出时调用