12

これには簡単な答えがあるはずですが、見つけるのに苦労しています(RSpecのドキュメント、RSpecを使用したEverydayRailsテスト、Googleの結果を確認しました)。私のモデル仕様では、次のように基本的な属性仕様を含めるのが好きです:

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) }
    ...

これらの仕様が気に入っているのは、工場やモデル内に何らかのエラーが発生した場合に、これらの仕様が迅速に特定するのに役立つからです。

私はexpect構文を他のすべての仕様に組み込みました。読み方は気に入っていますが、ここでの使用方法は? 1つのオプションは

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

そして別の可能性があります

expect(it).to respond_to(:color)

前者は構文で回避される重複を伴いshouldますが、後者は私には奇妙に見えます (それは私だけかもしれません)。

この質問は機能性よりもスタイルに関するものだと認識しています*。しかし、私たち Ruby 開発者はスタイルに注意を払っており、標準的な慣行に従い、読みやすく慣用的なコードを作成したいと考えています。どんな助けでも大歓迎です。ありがとう。

更新: ちなみに、私の提案したオプションはどちらも実際には機能しません。undefined method 'expect'どちらもエラーをスローします。今、私は本当に混乱しています！

エラーについて考えてみると、should上記の仕様が 1 行のブロック内にあるためだとわかりました。混乱するのは、expect 構文を使用して 1 行のブロックを記述するにはどうすればよいかということです。このアップデートを踏まえると、質問は機能性に関するものであり、他の人の意見を聞くのが楽しみです.

2015年4月更新

rspec > 3.0これらを処理するさらに別の方法が追加され、構文rspec ~> 4.0を廃止するように思えます。shouldMyron マスターごと:

一部のユーザーは、これが expect 構文にどのように関連するか、および引き続き使用できるかどうかについて混乱を表明しています。これは RSpec 3 でも引き続き利用できます (これも、構文構成に関係なく) が、expect 構文との一貫性が少し高い代替 API も追加しました。

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

is_expected は、expect(subject) として非常に単純に定義され、is_expected.not_to マッチャーを介して負の期待もサポートします。[...]
RSpec 3 では、should 構文を保持しており、デフォルトで使用できますが、明示的に有効にせずに使用すると、非推奨の警告が表示されます。これにより、RSpec 4 でデフォルトで無効化される (または別の gem に抽出される可能性がある) 道が開かれ、古いチュートリアルを介して RSpec に来る新規参入者の混乱が最小限に抑えられます。

4

2 に答える 2

16

RSpec のコア コミッターの 1 人である Myron Marston は、ここで、引き続き使用する必要があることを説明しています。

it { should be_cool }

構文を無効にした場合should、彼は次のようにエイリアスする解決策を提供していexpect_itます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

これを配置すると、これを次のように書くことができます。

describe User do
  expect_it { to be_valid }
end
于 2013-05-22T02:34:45.420 に答える
4

この質問に対する正しい答えはないと思いますが、最近、構文から離れて専用shouldの構文を使用するようにテスト スイートを書き直しているexpectので、2 セントを投じます。かなり書き直すことにしました。RSpec の主任メンテナであるMyron Marstonが次のように書いているためです。

今後、明示的に should を有効にしない限り、expect のみが利用できるようにデフォルトを変更する予定です。RSpec 3.0 でこれを行う可能性がありますが、ユーザーがそれに慣れるための十分な時間を与えたいと考えています。

彼はまたコメントしました：

「should」を削除する予定はありませんが、expect の方が落とし穴が少なく、新しいプロジェクトに推奨する構文です。

Mark Rushakoffの回答にも同意しますが、個人的には、単一のit-block スタイルの構文を維持するためだけにこれらのエイリアスを作成する必要はありません。したがって、あなたの例を使用して、最初に私があなたの例のようなモデル仕様をこの形式で書きました:

describe Foo do
  let(:foo) { create(:foo) }
  subject { foo }
  describe "model attributes" do
    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) }
  end
  # ...
end

私は今、次のように書く傾向があります：

describe Foo do
  let(:foo) { create(:foo) }
  specify "model attributes" do
    expect(foo).to be_valid
    expect(foo).to respond_to(:color)
    expect(foo).to respond_to(:height)
    expect(foo).to respond_to(:some_other_attribute)
    expect(foo).to respond_to(:you_get_the_idea)
  end
  # ...
end

私の意見では、foo直接 inを参照することは、間接的に using をexpect(foo).to respond_to(:color)参照することと同じくらい「重複」しているため、あまり段階的ではなく、仕様が一般的に読む方法に慣れています。しかし、最終的には、好みの文体の問題に過ぎないと思います。subjectitexpect

于 2013-05-22T03:00:09.147 に答える