加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 百科 > 正文

ruby – RSpec HaveSelector不能正常使用Capybara时的预期方式

发布时间:2020-12-17 02:20:53 所属栏目:百科 来源:网络整理
导读:Capybara的HaveSelector不与RSpec合作,期待我的期望.我是Capybara和RSpec的新手所以我这可能是对RSpec或Capybara的误解,或者它可能是Capybara(版本2.0.2)的缺陷.请帮助我理解我的错误或制作错误报告/功能请求. 在我的RSpec中,我写道: expect { click('.spec
Capybara的HaveSelector不与RSpec合作,期待我的期望.我是Capybara和RSpec的新手所以我这可能是对RSpec或Capybara的误解,或者它可能是Capybara(版本2.0.2)的缺陷.请帮助我理解我的错误或制作错误报告/功能请求.

在我的RSpec中,我写道:

expect { click('.special-div .submit') }.to have_css('.submitted')

我预计这在功能上等同于

click('.special-div .submit')
page.should have_css('.submitted')

但事实并非如此.相反,匹配器has_css尝试匹配proc对象的字符串转换,而不是调用proc对象的结果. (换句话说,从不执行click(‘.special-div .submit’).)

Capybara的行为是:

>非常合理
> Capybara缺少功能的一个例子
> Capybara 2.0.2中的一个错误
>还有别的吗?

此外,我显然可以通过使用上面的2行版本来做我想要的,但我们的团队正在尝试标准化expect {},那么有没有办法使用expect {}表单并让它做我想要的?

编辑

我继承了我正在使用的代码所以我没有意识到,正如Andrey Botalov指出的那样,click不是Capybara的标准部分.看起来应该是这样,但是再次点击已经大量用于其他事情,所以Capybara不会添加另一个定义可能会更好.

由于有些人似乎持怀疑态度,请允许我向您保证此代码工作正常:

click('.special-div .submit')
page.should have_css('.submitted')

对于那些对Have_css()感到疑惑的人来说,这对于has_css来说是RSpec魔术?对于那些想知道点击的人,在我的项目中,有人方便地创建了点击功能,如下所示:

def click(css)
    page.execute_script("$('#{css}').first().trigger('click');")
  end

为什么?因为没有明显的替代方案奏效.

click_on('.special-div .submit')  # Fails because click_on does not take CSS
# Cannot use click_button() because we are clicking on a <div>
find('.special-div .submit').click # Raises exception because there are more than one
first('.special-div .submit').click # Fails because the div is not visible

继续,@ zetetic问是否

expect(click('.special-div .submit')).to have_css('.submitted')

会工作.不,它对我们不起作用,因为我们仍然使用RSpec 2.9并且在2.11中引入了该语法,但即使我们升级它仍然无法工作,因为click不会返回对象.如果我们升级到2.11并将点击更改为返回页面,它可能会有效.

解决方法

期望{click(‘.special-div .submit’)}.to have_css(‘.enmitted’)有几个问题,这就是为什么我这么困惑.

最令我困惑的是RSpec期望{…}.到…语法.我认为这种语法会导致匹配器在{}中运行代码并将匹配器应用于结果或类似的东西.似乎在the example有意义:

expect { something }.to raise_error(SomeError)

事实证明,这通常不正确.只有某些匹配者期望“实际”(‘expect’和’.to’之间的内容)成为Proc然后调用它.大多数匹配者都希望“实际”成为一个对象.所以:

expect { 1 + 1 }.to eq(2)

尝试将Proc与Fixnum进行比较时引发异常.

所以Capybara的has_css? matcher在期望“实际”成为响应has_selector的对象时是完全合理的吗?而不是Proc.这真的是我的主要问题,因此,Capybara已经摆脱困境.

让我感到困惑的是,Capybara有助于提供DSL,以便在我的示例中使用has_css?相当于page.has_css?这让我期待have_css(css)会继续神奇地对抗页面.

关于编写测试的更好方法. @deviousdodo大多是正确的,这就是我为这个答案授予奖金的原因.我想要的是

expect {
  click('.special-div .submit') 
}.to change { page.has_css?('.submitted') }.from(false).to(true)

实际上,虽然它超出了原始问题的范围,但我真正想要的是

expect { 
  click('.special-div .submit')
  page.should have_css('.submitted')
}.to change { Click.count }.by 1

我想要这个的原因是因为我最想检查的是点击被记录在数据库中(Click.count增量)但是我必须等待点击完成的AJAX调用,这是由has_css完成的? .

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读