Factory_bot: 動的属性ブロック内のコンストラクター属性ハッシュへのアクセス? +ネストされた関連付け

作成日 2013年11月27日  ·  6コメント  ·  ソース: thoughtbot/factory_bot

_Googleグループでこれを2回聞いてみましたが、どちらの場合も私の投稿が消えました…:_

特定の属性がコンストラクターに渡されるかどうか(デフォルトを使用)で、別のことをしたいと思います。例:

quantity { constructor[:quantity] ? constructor[:quantity] + 5 : 10 }  #lazy attribute

したがって、コンストラクターで数量を指定するかどうかにかかわらず、数量の値は異なります。

FactoryGirl.build :item, quantity: 4   #==> item.quantity == 9
FactoryGirl.build :item   #==> item.quantity == 10

これは可能ですか?

PS:はじめにのドキュメントでは、defineブロックで関連付け属性の後に定義できたとしても、他の属性の前に関連付け属性が処理されるように指定するとよいと思います。

最も参考になるコメント

コンストラクターが提供するハッシュにアクセスして、レイジー属性ブロックで選択を行うために提供されたものを確認できればと思います…

http://stackoverflow.com/questions/31205859/factory-girl-can-we-check-if-an-attribute-has-been-overridden-in-its-lazy-attri

全てのコメント6件

あなたが探しているのは一時的な属性です

頑張ってください!

私は一時的な属性を知っていますが、私の場合、ファクトリのユーザーが一時的な属性を使用することを覚えておく必要はありません。
もちろん、私の実際のケースはこれよりも複雑です。 基本的に、ユーザーが数量属性を設定した場合に処理する必要のある数量依存関係があります(関連付け数量>数量を設定することにより)。

ブロックをタップできる「評価者」はありませんか?

@gamovは実際の例を提供できますか? このように数量を変更すると、間接的なレベルが導入されるため、実際に理想的かどうかはわかりません(値を設定した場合、値は割り当てられた値であり、変更されないと想定します)。

まず第一に、あなたの助けに感謝します。 私は要件を切り替えました、そしてそれはよりきれいな工場につながり、そして簡単に修正されたいくつかのテストを破っただけでした。 これで、ネストされた関連付けの数量は常に有効になります。

class ShippingItem < ActiveRecord::Base
   belongs_to :purchased_item
   validate { errors.add(:quantity, "cannot be higher than available quantity: #{purchased_item.quantity}") if purchased_item.quantity < quantity }
end

配送アイテム工場:

factory :shipping_item do
    quantity { rand 3..100 }
    purchased_item {association :purchased_item, quantity: (quantity..(quantity + 100)).to_a.sample}
end

これは、出荷品目ファクトリを呼び出すときに数量を設定するかどうかを設定すると正常に機能します(これは私の最初の質問でした)。
ここで、出荷品目工場から購入した品目の配送サイトを設定したいとします。 私はします:

factory :shipping_item do
    quantity { rand 3..100 }
    ignore {delivery_site nil}
    purchased_item {association :purchased_item, 
                                quantity: (quantity..(quantity + 100)).to_a.sample,
                                delivery_site: (delivery_site || FactoryGirl.build :delivery_site)
                            }
end

しかし、それがパターンになっているのを見ることができ、「正しい」または乾燥した感じはしません。 それは通常の方法ですか?

@gamovわかりました、これは今より理にかなっています、そしてはい、私はこれがDRYではないことに同意します。

このような場合(特にこれは単純なケースであり、はるかに複雑なケースがあるため)、実際に複雑なデータを構築するためのサポートクラスを作成します(関連するデータがたくさんあるか、特定の側面が変更され、作成に影響を与えるため)このような他の工場の)。 このような場合に私が指摘する例は次のとおりです: https

結局のところ、factory_girlは、オブジェクトが関連付けられて構築されるすべての方法のすべての順列を処理できません(そして処理しません!)。 それは不可能です。 変更がほとんどないあなたのような場合、私は常に純粋なRubyで問題を解決することをお勧めします。 必要に応じて、柔軟性、拡張性、および技術的にテスト可能です。

うまくいけば、これが役立つことを願っています-「factory_girlはこれをうまく処理できない」というのは理想的ではないように聞こえますが、factory_girlのインターフェイスをクリーンで理解しやすくし、奇妙なケースの可能性を排除するため、実際にはそうです。

コンストラクターが提供するハッシュにアクセスして、レイジー属性ブロックで選択を行うために提供されたものを確認できればと思います…

http://stackoverflow.com/questions/31205859/factory-girl-can-we-check-if-an-attribute-has-been-overridden-in-its-lazy-attri

このページは役に立ちましたか?
0 / 5 - 0 評価