自社開発プロダクト ALL-IN で行っている単体テストのパフォーマンスチューニングTips
0 likes3,959 views
「Matzから、Rubyパフォーマンスのポイントを教えてもらおう！会議」でのプレゼン資料です。 ビジネスバンクグループで自社開発しているプロダクト「ALL-IN」の開発における、単体テストのパフォーマンスチューニングのTipsについて発表しました。
More Related Content
What's hot (20)
Similar to 自社開発プロダクト ALL-IN で行っている単体テストのパフォーマンスチューニングTips (20)
![[TL09] 突撃! 隣の Visual Studio Team Services / Team Foundation Server ~利用者からのベスト...](https://cdn.slidesharecdn.com/ss_thumbnails/tl09-170614050650-thumbnail.jpg?width=560&fit=bounds)
Recently uploaded (11)
自社開発プロダクト 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 を使う ? 大量のデータをメモリに展開していない？ ? ?nd_each、?nd_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. あらかじめ顿叠登録してしまう
- 31. ? use_transactional_?xturesでテストケースごとにト ランザクションを効かせていても、このデータはテ スト完了後もDBに残る ? 何がしかの対策が必要 ? テスト起動時にDBをクリーンにするとか ? ユーザーIDを固定して、すでにあったら作らないとか ? やりすぎ注意 ? セットアップ時に色々登録すると、デフォルトで何が入っ てるのか分からなくなる デメリットもある
- 32. テスト分けすぎ问题
- 36. ? 本当に1テスト1Assertにすべきか？? → 意味的に同じことをテストしているのであれ ば、そこまで原理主義的にテストを分割しなくてい い? ? → DBアクセスが発生するテストは、テストメソッ ド数を減らすことでコストが下がる テストの最小単位とは？
- 38. ? and で繋げてまとめて確認? → RegistrationService.setup の評価は一回だけ こういうテストはどうする？
- 39. ということで
- 40. ? 無駄なデータを作らない ? FactoryGirlを上手に使う ? 同じようなデータを登録しない ? テストスィートセットアップ時に登録してしまう ? まとめられるテストケースはまとめる ? 分割しすぎず意味ある単位で１つにまとめる スピードアップの施策まとめ
- 43. どなたか m(_ _)m
- 44. Thank you !!