RSpec 'Expect' 语法和惯用属性规范 [英] RSpec 'Expect' Syntax and Idiomatic attribute spec

查看:24
本文介绍了RSpec 'Expect' 语法和惯用属性规范的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

这应该有一个简单的答案,但我很难找到它(已检查 RSpec 文档、使用 RSpec 进行 EverydayRails 测试、Google 结果).在我的模型规范中,我喜欢包含如下基本属性规范:

describe Foo do描述基本属性" do{ @foo = create(:foo) } 之前主题 { @foo }它 { 应该是_valid }它 { 应该 response_to(:color) }它 { 应该 response_to(:height) }它 { 应该 response_to(:some_other_attribute) }它 { 应该 response_to(:you_get_the_idea) }...

我喜欢这些规格,因为如果我的工厂和/或模型中存在某种错误,这些规格可以帮助我快速查明.

我已将 expect 语法合并到所有其他规范中,我喜欢它的读取方式,但如何在此处使用它?一种选择可能是

expect(@foo).torespond_to(:color)

另一个可能是

expect(it).to respond_to(:color)

前者涉及使用 should 语法避免的重复,但后者对我来说看起来很奇怪(可能只是我).

我意识到这个问题更多是关于风格而不是功能*,但我们 Ruby 开发人员对风格很认真,我想坚持标准实践并拥有可读的、惯用的代码.任何帮助表示赞赏.谢谢.

更新:顺便说一下,我提出的选项都没有实际工作.它们都抛出 undefined method 'expect' 错误.现在我真的很困惑!

考虑到错误后,我意识到这是因为上面的 should 规范在一行代码块内.那么,令人困惑的是,我如何使用 expect 语法编写单行块?鉴于此更新,问题与功能有关,我很高兴听到其他人的想法.

4/2015 更新

rspec >3.0 添加了另一种处理这些的方式,听起来像 rspec ~>4.0 将取消 should 语法.每迈伦大师赛:

<块引用>

一些用户对这应该如何与期望语法相关联以及您是否可以继续使用它表示困惑.它将继续在 RSpec 3 中可用(同样,无论您的语法配置如何),但我们还添加了一个与 expect 语法更一致的替代 API:

describe 后做它 { is_expected.to allow_mass_assignment_of(:title) }结尾

<块引用>

is_expected 非常简单地定义为 expect(subject) 并且还通过 is_expected.not_to 匹配器支持负期望.[...]
在 RSpec 3 中,我们保留了 should 语法,默认情况下它是可用的,但是如果您在没有明确启用它的情况下使用它,则会收到弃用警告.这将为在 RSpec 4 中默认禁用它(或可能被提取到单独的 gem 中)铺平道路,同时最大限度地减少通过旧教程进入 RSpec 的新手的困惑.

解决方案

Myron Marston 是 RSpec 的核心提交者之一,在此处进行了解释 你应该仍然使用

it { should be_cool }

如果您禁用了 should 语法,他提供了一种将 expect_it 别名为 it 的解决方案:

<块引用>

RSpec.configure 做 |c|c.alias_example_to :expect_it结尾RSpec::Core::MemoizedHelpers.module_eval 做别名应该别名 to_not should_not结尾

有了这个,你可以把它写成:

describe User doexpect_it { 为 be_valid }结尾

This should have an easy answer but I'm struggling to find it (have checked RSpec documentation, EverydayRails Testing with RSpec, Google results). In my model specs I like to include basic attribute specs as follows:

describe Foo do
  describe "basic attributes" do
    before { @foo = create(:foo) }
    subject { @foo }

    it { should be_valid }
    it { should respond_to(:color) }
    it { should respond_to(:height) }
    it { should respond_to(:some_other_attribute) }
    it { should respond_to(:you_get_the_idea) }
    ...

I like these specs because if there is some kind of error within my factory and/or model these specs help me pinpoint it quickly.

I've incorporated the expect syntax into all other specs and I like how it reads, but how to use it here? One option might be

expect(@foo).to respond_to(:color)

And another might be

expect(it).to respond_to(:color)

The former involves duplication that is avoided with the should syntax, but the latter looks strange to me (which could just be me).

I realize this question is more about style than functionality*, but we Ruby developers are conscientious about style, and I want to adhere to standard practices and have readable, idiomatic code. Any help is appreciated. Thanks.

UPDATE: Neither of my proposed options actually work, by the way. They both throw undefined method 'expect' errors. Now I'm really confused!

Having thought about the error, I realize it's because the should specs above are within one-line block. The confusion, then, is how can I write a single-line block with the expect syntax? In light of this update, the question is very much about functionality and I'll be excited to hear others' thoughts.

4/2015 UPDATE

rspec > 3.0 has added yet another way of handling these, and it sounds like rspec ~> 4.0 will do away with the should syntax. Per Myron Masters:

Some users have expressed confusion about how this should relates to the expect syntax and if you can continue using it. It will continue to be available in RSpec 3 (again, regardless of your syntax configuration), but we've also added an alternate API that is a bit more consistent with the expect syntax:

describe Post do
  it { is_expected.to allow_mass_assignment_of(:title) }
end

is_expected is defined very simply as expect(subject) and also supports negative expectations via is_expected.not_to matcher. [...]
In RSpec 3, we've kept the should syntax, and it is available by default, but you will get a deprecation warning if you use it without explicitly enabling it. This will pave the way for it being disabled by default (or potentially extracted into a seperate gem) in RSpec 4, while minimizing confusion for newcomers coming to RSpec via an old tutorial.

解决方案

Myron Marston, one of the core RSpec committers, explains here that you should still use

it { should be_cool }

If you've disabled the should syntax, he offers a solution to alias expect_it to it:

RSpec.configure do |c|
  c.alias_example_to :expect_it
end

RSpec::Core::MemoizedHelpers.module_eval do
  alias to should
  alias to_not should_not
end

With this in place, you could write this as:

describe User do
  expect_it { to be_valid }
end

这篇关于RSpec 'Expect' 语法和惯用属性规范的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆