3

Giant Robots Smashing Into Other Giant Robots ポッドキャストを聞いていると、FactoryGirl ファクトリを最小限にして、オブジェクトをデータベースで有効にする属性のみを提供する必要があると聞きました。そうは言っても、将来変更される可能性のある属性に基づいて特定の動作を定義するには、特性が非常に優れた方法であるという話も続きました.

意図的に検証を失敗させて仕様コードをクリーンアップする特性を定義することも良い考えであるかどうか疑問に思っています。次に例を示します。

factory :winner do
  user_extension "7036"
  contest_rank 1
  contest

  trait :paid do
    paid true
  end 

  trait :unpaid do
    paid false
  end 

  trait :missing_user_extension do
    user_extension nil 
  end 

  trait :empty_user_extension do
    user_extension ""
  end 

end

build_stubbed(:winner, :missing_user_extension)検証に失敗する予定のテストで仕様を呼び出すことができます。と呼ばれる別のファクトリの下にこれらの悪いファクトリをネストすることで、この明示的な失敗をさらに進めることができると思いますが:invalid_winner、それが必要かどうかはよくわかりません。私は主に、この概念に関する他の人の意見を聞くことに興味があります。

4

1 に答える 1

5

いいえ、それは良い考えではありません。しばらくすると仕様が明確に理解できなくなり、後でコードが進化したときに、今日失敗したファクトリはもう失敗しない可能性があり、すべての仕様を確認するのに苦労することになります。

明確に識別された 1 つのものに対してテストを作成する方がはるかに優れています。必須パラメータが欠落しているために保存が失敗することを確認したい場合は、通常のファクトリでそれを記述し、パラメータを追加してファクトリの値を上書きするだけです。

it 'should fail' do
  create :winner, user_extension: nil 
  ...
end
于 2013-08-01T03:43:32.180 に答える