FactoryGirl導入 #TechLunch

FactoryGirl導入
2013年1Q RC opening
2013/11/06 (水) @ Livesense TechLunch
発表者：松永 一郎

Transcript

1. FactoryGirl導入 PlatformHR作成過程のKnowhow共有 その1
2. 諸君、私はテストが大好きだ!! この地上で行なわれるありとあらゆるテストが大好きだ。 テストを並べたrspecやcucumberの一斉実行が .... と共に成功を返すのが好きだ 以前までredやyellowだったテストがリファクタリングや修正でgreenになった時など心がおどる スケジュールに滅茶苦茶にされるのが好きだ 必死に作るはずだったテストがpendingとだけ記載されてカバレッジが下がっていく様はとてもとても悲しいものだ 色々な要求に押し潰されテストが後回しにされるのが好きだ 色々な要求に追いまわされ外注の様に動作保証が出来ないcodeを作るのは屈辱の極みだ 諸君 私はテストを、リファクタリングが可能な量のテストを望んでいる 諸君 私に付き従うプロジェクトメンバー諸君 君達は一体なにを望んでいる？ 更なるテストを望むか? 情け容赦のない糞のようなコードを望むか? 鉄風雷火の限りを尽くし三千世界のバグやエンバグを炙り出す嵐の様なテストを望むか？ よろしい、ならばテストだ 少佐、かわいいよ、少佐
3. • activerecord • activecontroller • partial • api • railsの仕組みに乗ってないコード • 業務フロー PlatformHRで行なっている自動テスト対象
4. 前提 ActiveRecordの場合、dbと密になっており、on memoryなテス トを構築するのは面倒なので厳密な意味でのunit testでは無い 方法を採りました。 また、rails界隈のactiverecord系のテストツールも基本dbを使 う物が多いようです。 そういうわけで、dbとの連携を前提としたテストで行ないます。
5. 通常良く使われるfixtureによる開発 ActiveRecord::TestFixtures::ClassMethods#fixtures を使って、rspecファイル毎にdbをリセットする(設定によっては この限りでは無い。テスト毎のリセットはtransaction)。 なお、基本fixtureファイル名とテーブル名は一致させる必要が あり、別のファイルをloadする場合は色々と面倒。
6. fixture使う場合のcode engines.platform-hr.jp/spec/models/companies_spec.rb(tag: gem_0.1.17) require ‘spec_helper’ describe Comapny do fixtures Dir.new(fixture_path).grep(/^[^\.]/).map{|f| f.gsub(/\.yml/, '').to_sym} ….. fixtureがデフォルトで読まれるdirectory下から、テーブル名のシンボルを準備し、 fixturesメソッドに渡している。 このテストで使うレコード/使わないレコードの分別が面倒なので、基本、全テーブル 放り込んでいる。
7. この場合のデメリット • テスト毎にfixtureを切り替えたくても面倒 • fixtureの初期準備や、テーブル構成の変更時 の追従がかなり大変 • ちゃんとしたリレーション状態を保つのも大変 よーするにすごくたいへん
8. FactoryGirlってなに？ 大雑把にいうと。 FactoryGirlとは、FactoryGirlのコンテキストに、あ るテーブルのあるレコードを新しく頂戴(書込み済 みも、未書き込みも両方OK)とすると、対象の ActiveRecord instanceが返却される仕組み。
9. 少し細かく言うと。 • FactoryGirlはテーブル毎にFactoryを定義し て、それに従ってrecordが作成される。 • Factoryからrecordを取り出す際に、定義を上 書きする事も可能。 • また、Factoryの定義内にロジックを入れて色々 する事が出来る。
10. 実際のFactoryの定義 定義 spec/factories/resumes.rb
11. Factoryの定義 2,3行目 FactoryGirl.define do factory :factory名 do 各種定義 end end
12. 簡単な使いかた(生成) dbに作成された状態を作る $record = FactoryGirl.create(:resume) dbにpersist前の状態を作る $record = FactoryGirl.build(:resume) 100件作る $records = FactoryGirl.create_list(:resume, 100)
13. 簡単な使いかた(初期値上書き) Factoryの定義の値を上書きして別の値を使う $record = FactoryGirl.create(:resume, :medium => hoge_medium) $record = FactoryGirl.create(:resume, :name_ruby => ‘イチ ロー’)
14. 簡単な使い方 (trait) traitにより、create/buildする際にロジックを分ける事が出来る 例(users) $admin = FactoryGirl.create(:user_admin) $owner = FactoryGirl.create(:user_owner) 呼出側で適用とかも出来る $admin = FactoryGirl.create(:user, :admin)
15. 定義 固定値 20行目 name_ruby ‘ふりがな’ これにより生成される際はいつでも ふりがな が値 として入ってくる。
16. 遅延評価 FactoryGirlの値はFactoryの定義が評価された時に決定する。逆に言うと、factory で生成する毎に値を変えたい場合は遅延評価( {}でくくる )する必要がある。 hoge_time Time.now とした場合、何度取り出しても、同じ値が出てくる 22行目 以下のようにすると遅延評価され、factoryで生成する度に18-58年前のバラバラの 日付を作る事が出来る birthday { Date.today.years_ago( 18 + rand(40) ) - rand(100)}
17. 連番 7行目 sequence(:medium_member_id){|n| “medium-member-id-# {n}”} 生成される度にnがカウントアップされ、その結果をゴニョゴニョ した値をrecordにセットする これを利用すると nのmodを取ったりして色々データに色を出 す事が出来る
18. 他のFactoryとの連携 5行目 association :medium, :factory => :medium ResumeはMediumをbelongs_toしてリレーション している。 この定義により、指定無い場合は自動でmedium が作られ、関連付けされる(db的にも)
19. traitの作成 前述のように、traitという機能によりfactoryに色を 出す事が出来る spec/factories/users.rb:15-24 spec/factories/resumes.rb:9-18
20. FactoryGirlの組込 FactoryGirlはデータ作成の為の物なので、persist したデータのクリーニングが必要。 そこで、DatabaseCleanerというgemとセットで使う 事が多い。
21. DatabaseCleaner 以下の機能を持つgem • clean_with ◦ いくつかの方式でdbをクリアする ◦ truncateとかtransactionとかdeleteとか • start ◦ 戻しポイントの指定(begin tranみたいなの) • clean ◦ 戻す(rollback的な)
22. どう組み合わせるか PlatformHRの基本的なやりかた その1（scoutで多用) • DatabaseCleanerのstrategy(start/cleanをどのように行なうか)をtransaction指 定で行なう。 1. rspecの根っこ(L1)のbefore :allで初期状態作成 a. DatabaseCleaner.clean_withでtruncate b. truncateは重いので、対象テーブルを指定 2. L1のbefore :each でDatabaseCleaner.start 3. L1のafter :each でDatabaseCleaner.clean ただし、既存のfixtureが使えない。
23. どう組み合わせるか PlatformHRの基本的なやりかた その2（fixtureを使った既存テストの多いengines側 でのやりかた) • そのままfixturesでloadすると、テスト毎にrollbackが走り、rspecのcontext内で 共通的にFactoryGirlで作成した値が飛んでしまう。 • fixturesでtransactionを使わず、テスト毎にdbへfixtureをロードする方法もある が、テスト実行が重くなる なので、fixtureのロードのタイミングに関しては自前で組み込んだ。 注意点として、db/seeds.rbを使っていると、このデータも飛ばされてしまうため、 fixtureに寄せた。どーせproductに対するマスター投入なんか初回しかやらないし。
24. 最後に • テストがあれば万事OKってわけじゃないけど、テストが無い と出来ない事はいっぱいあるので、ちゃんとテスト書きましょ う。 • でもなんでもテスト書きゃ良いってもんでも無くて(開発時/仕 様変更時の工数が膨らむ)、ちゃんと観点をもって書きましょ う。 • でもcontroller/modelでのcoverageは100%(組み合わせが あるのでそれ以上)が望ましいと思う。 • Magical Factory Girlに期待。