自社開発プロダクト ALL-IN で行っている単体テストのパフォーマンスチューニングTips
•
0 j'aime•3,955 vues
「Matzから、Rubyパフォーマンスのポイントを教えてもらおう！会議」でのプレゼン資料です。 ビジネスバンクグループで自社開発しているプロダクト「ALL-IN」の開発における、単体テストのパフォーマンスチューニングのTipsについて発表しました。
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à 自社開発プロダクト ALL-IN で行っている単体テストのパフォーマンスチューニングTips
Similaire à 自社開発プロダクト ALL-IN で行っている単体テストのパフォーマンスチューニングTips (20)
Dernier
Dernier (12)
自社開発プロダクト ALL-IN で行っている単体テストのパフォーマンスチューニングTips
- 2. • 竹中 翔 • ビジネスバンクグループ CTO • Twitter/GitHub @shoutakenaka 自己紹介
- 3. • 中小企業向けクラウドERPソフト • 経営を支援する「ビジネス・コックピット」 → 詳しくはこちらの動画にまとめられていますの で、是非ご覧ください • Ruby on Rails • 2015年7月にファーストリリース • 鋭意開発中 ALL-IN
- 4. • 壮大なコンセプトのシステム • 設計 → 開発 → リリース → 検証 → 改善 → … • 自動テスト大事！ ALL-IN
- 5. はじめの一歩
- 7. そして今
- 11. • rspec • resque_spec • factory_girl • database_cleaner • faker 主なテスト用gem
- 12. • 時間がかかるのは主に外部リソースアクセス（I/ O）。 • DB • File • Web API • ALL-IN の場合、外部の Web API をあまり使ってい ないので、I/O は DB アクセスがメイン。 スピードアップのポイント
- 13. • テストケース数が増えてくると、個々のテストの ちょっとしたスローダウンが、全体で見ると大きな 影響に… • 0.1 sec * 20000 = 2000 sec = 33 min スピードアップのポイント
- 14. • プロダクションコードで非効率な I/O を発生させな いのは当然大切！ • N+1 問題発生してない？ • includes とか eager_load を使う • 大量のデータをメモリに展開していない？ • find_each、find_in_batches を使う • kaminari gemとか offset、limit でページングする スピードアップのポイント
- 15. • テストのセットアップも大切！ • 不要なテストデータを DB に入れてない？ • 同じようなデータをテストのたびに毎回DBに入れてな い？ → 適切なタイミングで、必要なデータを投入する！ スピードアップのポイント
- 16. 不要なデータ問題
- 18. • テスト用のモデルインスタンス＋DBへのデータ登 録が楽にできる • デフォルト値でよければcreateするだけ • テストケースに合わせて、柔軟に特定の属性だけ上書き できる • create_list(:customer, n) で n個まとめてインスタンス生 成＋DB登録できる FactoryGirlを使うと
- 19. でもちょっと待った
- 20. • モデルのインスタンスさえあれば、DBにデータが 入っていなくてもいいテストはある • モデルのバリデーションのテスト • モデル → JSON のレンダリングのテスト • DBアクセスを伴わない計算ロジックのテスト • etc • これらのテストケースまで create でインスタンス を作るのは無駄 DB登録は本当に必要？
- 22. • 関連モデル（アソシエーション）はINSERTされて しまう → この例だと customer_status はやっぱりDB登録 されてしまってる… buildの罠
- 24. • ブロックを渡すと、必要になったときにブロックの 中身を評価して属性値を作ってくれる → ALL-IN ではこの書き方 遅延評価でもOK
- 26. 頻繁に登録されるデータ問題
- 28. • 何も考えずにこんなコードを書くと、各テストケー スのセットアップで毎回 user をDBに登録する処理 が走ってしまってコストが高い 例えばログインユーザー
- 29. あらかじめDB登録してしまう
- 31. • use_transactional_fixturesでテストケースごとにト ランザクションを効かせていても、このデータはテ スト完了後もDBに残る • 何がしかの対策が必要 • テスト起動時にDBをクリーンにするとか • ユーザーIDを固定して、すでにあったら作らないとか • やりすぎ注意 • セットアップ時に色々登録すると、デフォルトで何が入っ てるのか分からなくなる デメリットもある
- 32. テスト分けすぎ問題
- 36. • 本当に1テスト1Assertにすべきか？ → 意味的に同じことをテストしているのであれ ば、そこまで原理主義的にテストを分割しなくてい い → DBアクセスが発生するテストは、テストメソッ ド数を減らすことでコストが下がる テストの最小単位とは？
- 38. • and で繋げてまとめて確認 → RegistrationService.setup の評価は一回だけ こういうテストはどうする？
- 39. ということで
- 40. • 無駄なデータを作らない • FactoryGirlを上手に使う • 同じようなデータを登録しない • テストスィートセットアップ時に登録してしまう • まとめられるテストケースはまとめる • 分割しすぎず意味ある単位で１つにまとめる スピードアップの施策まとめ
- 43. どなたか m(_ _)m
- 44. Thank you !!