LoginSignup
18
9

More than 3 years have passed since last update.

Railsアプリからdatabase_cleanerを外したらRSpecが30%速くなった話

Last updated at Posted at 2019-10-07

RSpecでdatabase_cleanerを使っているRailsアプリからdatabase_cleanerを外したら結構速度が速くなったので、そのときの話を書きます。

database_cleanerを使うことでテストの速度が遅くなっていたり消しちゃいけないテーブル(ar_internal_metadata)まで消していたり様々な問題に薄々は感づいていたのですが、動いていたので放置していました。直ちに影響はないってやつですね。
今回、ちょうどリファクタリングの時間が取れそうだったのでdatabase_cleanerを外すことにしました。

database_cleanerとは

テスト実行時にテストデータをクリアしてくれるgemです。
(設定次第ですが)テスト前後で全テーブルをtruncateしてくれます。
https://github.com/DatabaseCleaner/database_cleaner

外そうと思った理由

RspecがテストごとにRollbackしてくれる

今のRSpecはテストごとにデータをRollbackしてくれます。そのためtruncateをする必要がありません。
before(:all)など大きなスコープで作ったデータはRollbackされませんが、テストの独立性を考えるとbefore(:all)を控えたほうが良いのでそこも可能な限り潰してdatabase_cleanerが必要ない状態に持っていきたい。

いろんなところに設定が増殖していた

下記のようにrails_helperにdatabase_cleanerの設定していました。

spec/rails_helper.rb
config.before(:suite) do
  DatabaseCleaner.strategy = :transaction
  DatabaseCleaner.clean_with :truncation
  require Rails.root.join 'db', 'seeds'
end

config.around(:each) do |example|
  DatabaseCleaner.cleaning do
    example.run
  end
end

ただ、長い歴史を経て個別のspecにもdatabase_cleanerの設定が書かれてしまっていました。
下記のように個別に書かれるとそのテストを単体で実行している分には問題ないのですが、これ以降に動く全specに反映されてしまいます。
そのため後半のspecでは1つのテストで同じtruncateが2回も3回も動いていました・・・

spec/requests/class_name_spec.rb
RSpec.describe ClassName do
  RSpec.configure do |config|
    config.after :all do
      DatabaseCleaner.clean_with(:truncation)
    end
  end
  ・・・
end

間違った使い方をしているのが悪いと言えばそうなのですが、複数人で開発していると間違いを完全に防ぐことは難しいのでそもそも間違えづらいようにしておくことがベターだと思っています。

ar_internal_metadataも消しちゃう

Rails5からar_internal_metadataというテーブルが作成されるようになりました。
database_cleanerは特別な設定を入れない限り全テーブルをtruncateするのでこのテーブルも削除してしまいます。
これを消されるとdb:migrate:resetなどで直さないとテストがうまく動かなくなります。
database_cleanerの設定で消したくないテーブルを指定できるが、今後もそういうテーブルが増えるたびに事故りそうなのでやめたい。

スピードが遅い

truncateはそれなりに時間がかかります。これがspecごとに行われるのでテストが増えるごとにどんどん遅くなっていきます。
また、今回リファクタリングするRailsアプリでは無駄にtruncateが複数回動いていたのでさらに遅くなっています。
specごとに下記の塊が実行されていまいた。(しかも後半のspecではこれが複数回・・・
truncate.png

database_cleanerを外す前の実行時間は下記の通りでした。

Finished in 5 minutes 57 seconds (files took 11.06 seconds to load)
1366 examples, 0 failures, 5 pending

database_cleanerを外す

まずはGemfileからdatabase_cleanerを削除してbundle install

Gemfile
-  gem 'database_cleaner'

次にdatabase_cleanerの設定を全て消します。database_cleanerDatabaseCleanerなどでgrepしました。

最後にテストがトランザクション内で行われてテスト後にrollbackされる様に設定します。
(実際に作業した時はこの設定を戻し忘れて半日くらいハマりました・・・)

spec/rails_helper.rb
RSpec.configure do |config|
  ・・・
  config.use_transactional_fixtures = true
  ・・・
end

とりあえずテスト実行。・・・全部成功だと!?

1366 examples, 0 failures, 5 pending

だが私は知っている。before :allでデータを作っているテストがあることを。
before :allでデータを作るとロールバックされません。
ということで再実行。予想通りいくつか失敗しました。

1366 examples, 9 failures, 5 pending

失敗するテストが分かったのでbefore :allでデータを作っている箇所を地道に潰します。
before :allで作られたデータはDBに残っているのでdb:migrate:resetなどで都度削除するのを忘れない様にしましょう。

単純にbefore :allbeforeに修正して必要に応じて定義位置を変えるだけでほとんどのエラーは潰せたのですが、MySQLの全文検索(N-gram)のテストケースで詰まりました。
下記に記載されている通り、全文検索ではコミットされたデータのみ表示できるようになります。before :allを外すことでコミット前のデータにアクセスすることになるのでデータが取得できなくなってしまいました。
https://dev.mysql.com/doc/refman/5.6/ja/innodb-fulltext-index.html#idm139827143719712

before :allを外す方法が思いつかなかったので、全文検索のテストはbefore :allでデータを作り、after :allで手動でデータを削除することにしました。
もっと良い方法をご存知の方がいらっしゃればぜひご教授くださいmm

最終結果

対応後にRSpecを実行したら(多少のばらつきはありますが)1分半ほど高速になりました。目に見えて速くなると嬉しいですね。

Finished in 4 minutes 7.5 seconds (files took 7.8 seconds to load)
1366 examples, 0 failures, 5 pending

RSpecはgit pushするたびに実行していたのでCI(circleciを使っています)の混雑が多少は緩和されたのではないかと思います。
テストのリファクタリングは優先度が低く設定されがちですが、RSpecが遅いと地味にエンジニアの工数を取ってしまうし、重要視されていない分改善の余地は多そうなので、今後も時間をとって改善していきたいと思います。

18
9
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
18
9