2

私はrailstutorial.orgでチュートリアルを進めてきましたが、セクション-6.2.1プレゼンスの検証の作成者のコードに少し困惑しました。

ユーザーモデルでは、チュートリアルはを追加しますvalidates :name, :presence => true。十分に単純です。

著者がrspecテストを書くことを選択したとき、彼は私が少し奇妙だと思った何かをします。

describe User do

 before(:each) do
   @attr = { :name => "Example User", :email => "user@example.com" }
 end
 .
 .
 .
 it  "should require a name" do
  no_name_user = User.new(@attr.merge(:name => ""))
  no_name_user.should_not be_valid
 end

end

@attr空白の文字列をマージして、：eachブロックステートメントを削除して次のように記述できるようにするのに、なぜ問題が発生するのでしょうか。

it "should require a name" do
  no_name_user = User.new(:name => "", :email => "user@example.com")
  no_name_user.should_not be_valid
end

著者が変数を使用して電子メールアドレスの存在も検証していることを知ってい@attrます。これは、彼がブロックステートメントを使用した理由の1つの指標です。私にとっては、2番目のブロック引用符の構造に従う方が理にかなっています。それでも、ここに欠けているものがあるような気がします。

私の頭に浮かんだもう1つの説明は、@attr名前と電子メールだけのこのかなり単純なケースとは対照的に、入力するキーがたくさんあるときに構造を使用すると役立つということです。

誰か入力がありますか？

4

2 に答える 2

1

ポイントは、テストのテスト ケースに関連するコードのみを含めることです。ユーザーが名前なしで有効でないことをテストするときに関連する唯一の属性は、name 属性です。このテストでは、email 属性について何も知る必要はありません。

新しいフィールドが存在するかどうかの検証を追加するとします。そのフィールドを使用せずに User を構築するすべてのテストを更新する必要があります。上部にあるattrハッシュを使用して、そこに新しいフィールドをポップするだけで、すべてのテストがうまくいきます。

テスト用のオブジェクトを作成することは、多くの解決策があり、どの方法が最適かについて多くの議論があるほど一般的な問題です。工場見学をお勧めします。Machinist と FactoryGirl は、Rails でうまく機能する 2 つの代替手段です。

于 2011-09-14T21:28:17.317 に答える
1

これは、すべてのテストで使用できる 1 つの標準属性マップがあるためです。テストで値が存在しないことが必要な場合、その値は削除されます。

個人的には、（あなたが発見したように）物事を難読化するので、それだけの価値があるとは確信していませんでしたが、そこにあります.

于 2011-09-13T23:23:42.453 に答える