RSpecのテストコードを実行時に書き換えて実行速度を改善した話 - STORES Product Blog
CTOの藤村です。つい最近まで STORES ブランドアプリ のチームでRailsを書いていました。 STORES ブランドアプリ のRailsリポジトリではdatabase_cleanerを（strategy = truncationで）使ってテスト中のデータベースをリセットしており、このことがテストコードの品質、速度などで重荷となっていました。 これを、テスト実行時にテストコード自体を書き換えて改善する仕組みを作り、先日無事Transactional Testへの移行が完了しました。ということで気分がとてもよいので、どうやったか共有させてください。 課題 STORES ブランドアプリのRailsのテストコードは速度に課題がありました。 テストデータを片付ける仕組みとして、 Railsエンジニアにはお馴染みのdatabase_cleanerというGemを使っていました。database_
Rails Developers Meetup 2019で、再び綺麗なテストコードの書き方について発表した - おもしろwebサービス開発日記
先日行われたRails Developers Meetup 2019で、Clean Test Code Revisedというタイトルで発表しました。スライドはこちら。 動画も上がっているようなので興味のある方はどうぞ*1。 所感 ご存知のかたもいると思いますが、この発表は2017年5月に行われたRails Developers Meetup第一回目で発表した内容を更に一歩進めたものとなっています。 Rails Developers Meetup で綺麗なテストコードの書き方について発表した - おもしろwebサービス開発日記 当時僕の頭の中にあった「こういうケースのときはこう書く。なぜならこうだから」というものを点で出したのが前回の発表で、それらを「脳に負荷をかけない」という線でつなげてまとめたのが今回の発表になります。 テストコードをレビューしたときに「これなんか読みづらいな…」と思って
RSpecモックメモ
double完全に偽物のオブジェクトを作る。allowなどで定義されていないメソッドを呼び出すとテストが失敗する。 d = double('object') d.hoge #=> 失敗 d = double('object', hoge: 1, piyo: 2) expect(d.hoge).to eq 1 #=> 成功 d = double('object') allow(d).to receive(:hoge) expect(d.hoge).to eq nil d = double('object') allow(d).to receive_messages(hoge: 1) expect(d.hoge).to eq 1 spyほとんどdoubleと同様だが、allowなどで定義していなくても任意のメソッドを呼び出せる。コードは確認していないが、double(...).as_null_
RSpecでexitを含むコードをテストする - pockestrap
TL;DR expect{subject}.to raise_error SystemExit exitをテストする状況はそもそも筋が悪い 前置き こんにちは。私は最近miというRails用のマイグレーションジェネレータを作っています。 github.com Railsのジェネレータは内部でThorというライブラリを使用しています。 このライブラリを使用していく上で、一つ問題が発生しました。 処理を途中で切り上げるためにexitメソッドを使用しないといけない事態に陥ってしまっていました。 問題点 exitはその時点でプロセスを終了するメソッドです。 このメソッドの問題点の一つに、テストがしづらくなると言うことがあります。 例えば、以下のようなメソッドをテストすることを考えます。 def do_something # ... if cond # ... exit 1 end # ... en
CircleCIの消費クレジットとRSpecの実行時間を半減させるために行った9の手順
概要この記事はCircleCI Advent Calendar 2020の9日目の記事です。 スタディスト開発部の笹木です。今年に入ってからは開発基盤チームという位置づけで、開発環境の整備や、CI含むテスト自動化周りを担当しています。 本記事では、RSpecのテスト実行時間を半減させ、CircleCIの消費クレジットを大幅削減した取り組みについてご紹介します。(消費クレジットについては後述します) 改善の結果が以下のグラフで、定点観測しているジョブの消費クレジットが、ピーク時の半分にまで落とせていることがわかります。もちろんテストコードを減らすといった本末転倒なことはしていません。 RSpecジョブ実行時の、CircleCI消費クレジットを時系列で表したグラフ実施した取り組みは以下の通りです。 CircleCIの料金体系を知る問題を認識するCircleCIの利用状況を可視化するRSpecの
RailsプラグインGemの作成方法、RSpecテストまで含めたrails pluginの作り方
Rails プラグイン Gem を作る方法の紹介です。現在の Rails では、プラグインを Gem としてビルドします。通常の Ruby Gem と異なるのは、Rails プラグイン Gem は Rails のコアフレームワーク自体を拡張することができる点です。Rails 自身を拡張して機能を追加したい場合は、Rails プラグインとして Gem を作成すると良いでしょう。 通常の Ruby Gem の作り方は、以下を参照お願いいたします。 Gemの作り方(Ruby Gem) | EasyRamble また、Rails でライブラリとして組み込むことができる gem には、通常の Ruby Gem、Rails プラグイン、Rails エンジンの3種類があります。それぞれの違いについては、以下の解説がとても分かりやすいです。 Gem、Railtieプラグイン、Engine（full/mou
scenario内の一部分をリトライできるrspec-retry_exの紹介 - ENECHANGE Developer Blog
プラットフォーム事業部のtaki（@yuyasat）です。 昨年10月のブログでenechange の feature spec がランダムで落ちる事象への対応について、２つのリトライ機構を利用している旨を紹介いたしました。 一つは、rspec-retry gem の利用、もう一つは rspec-retry_ex gem の利用です。前者のrspec-retry gemは、feature specのscenario単位でのリトライを行うgemでこれはすでに公開されているgemを利用しました。一方、後者の rspec-retry_ex は scenario の中の expect 単位でリトライを行う gem です。こちらは、公開されている gem がなく、私が実装を行い、gem として公開いたしました。 本記事では rspec-retry_ex を gem として公開するまでの経緯を紹介した
gemを作る時に気をつけていること - くりにっき
公私含めて2年間でたぶん30個以上はgemを作ってますが、なんとなく体得はしたもののこういうことは誰も教えてくれなかった気がするので残しておきます アンダースコアとハイフンを使い分ける gemを作る第一歩は bundle gem <作りたいgemの名前> ってやると思いますが、単語区切りであればアンスコ、ネームスペースの区切りだったらハイフンを使います アンダースコア区切り $ bundle gem go_princess_precure Creating gem 'go_princess_precure'... create go_princess_precure/Gemfile create go_princess_precure/.gitignore create go_princess_precure/lib/go_princess_precure.rb create go_pri
RSpec の expect_any_instance_of でハマった - ドン・エンジニーア
class Test def say_hoge hoge1 = Hoge.new hoge2 = Hoge.new hoge1.say hoge2.say end end class Hoge def say puts 'hoge' end end こんな感じのクラスがあったとして、 Test#say_hoge で Hoge インスタンスが Hoge#say を1回ずつ実行していることをテストしたいとなったときに、以下のようなテストを書きました。 describe 'Test' do describe '#say_hoge' do it 'Hoge インスタンス は Hoge#say を1回ずつ実行する' do expect_any_instance_of(Hoge).to receive(:say).once test = Test.new test.say_hoge end end e
S3 を使った実装のテストを fake-s3 を使って書いてみる - こしごぇ（Ｂ）
koshigoe/fakes3-exercise fakes3 (fake-s3) という gem を使うと、S3 のダミーサーバ(webrick)が使えるようになるとのこと。 fakes3 と fakefs で Amazon S3 連携のテストを書いてみた - あらびき日記 jubos/fake-s3 サーバプロセスの管理をどうするのが今っぽいのか分からず、ググって得られた情報を元に、glint という gem を使ってみることに。 kentaro/glint before(:suite) で glint に fakes3 の面倒を見てもらう。 after(:suite) は、fakes3 に渡した一時ディレクトリの後始末を行うのみ。 # spec/support/fakes3.rb require 'tmpdir' require 'glint' RSpec.configure do
RSpec で Active Job のテストを書く - milk1000cc
追記(2016/11/11 10:33): この記事の内容は古くなっており、あまりおすすめしません。RSpec 公式の方法をお使い下さい。 have_been_enqueued matcher - Matchers - RSpec Rails - RSpec - Relish have_enqueued_job matcher - Matchers - RSpec Rails - RSpec - Relish 追記ここまで Rails 4.2.1 で確認しています。 Post#ping で、10 分後に PingJob をエンキューするというテストを書いてみます。 spec/rails_helper.rb RSpec.configure do |config| config.include ActiveJob::TestHelper config.include ActiveSupport
RSpec 3.3 has been released!
Myron MarstonJun 12, 2015RSpec 3.3 has just been released! Given our commitment to semantic versioning, this should be a trivial upgrade for anyone already using RSpec 3.0, 3.1 or 3.2, but if we did introduce any regressions, please let us know, and we’ll get a patch release out with a fix ASAP. RSpec continues to be a community-driven project with contributors from all over the world. This releas
RailsのRSpecテストを速くする方法まとめ - Rails Webook
Photo by Flickr: chief_huddleston's Photostream Railsの規模が大きくなると自動テストの実行時間もだんだんと長くなっていきます。素早く開発していくにはテストの実行時間を短くすることが大切です。 RSpecのテストを速くする方法をまとめましたので参考にしてください。 動作確認 Rails 4.1 rspec-rails 3.1.0 test-queue 0.2.9 目次 1. RSpecのパフォーマンス測定 2. test-queueで並列でテストを実行する 3. rspec-guardを使って更新したファイルを自動的にテストする 4. Springを使ってテストのロード時間を短くする 5. ログレベルを変える 6. GCを実行を抑える 7. RSpecファイルのリファクタリングをする 7.1. itを少なくする 7.2. createよりも
Rails勉強会まとめ -- 非同期処理/RSpecなど｜TechRacho by BPS株式会社
こんにちは、hachi8833です。 今回は棚卸しとして、弊社CTOのbabaさんによるRails勉強会スライドから引用して記事にします。 勉強会自体はRails 3.x時代のものなので既出が多くなっていますが、棚卸しも兼ねて今のうちに記事にいたしました。 非同期処理 言うまでもなく、リクエストからレスポンスまでの時間が長くなるほどユーザー・エクスペリエンスの質が低下します。これを改善するためにさまざまな工夫が必要になるわけですが、その中の一つとして、時間のかかる処理をバックグラウンドで実施しておくというのがあります。 cron 最も素朴な方法はやはりunix標準のcronを使って定時に出力データを準備することでしょう。この場合、起動用スクリプト(rakeなど)やジョブ管理は自分で作成する必要があります。 delayed_job delayed_job gemを使用すると、ジョブをActi
RSpec をやめて Test::Unit に戻る - tmtms のメモ
最近の RSpec は、それまで obj.stub(hoge: value) と書けたものが、 allow(obj).to receive(:hoge).and_return value と書かないといけなくなったりとか、正気の沙汰とは思えないような変更をしたりするので、何年かぶりに Test::Unit を使ってみようとリハビリ中です。 RSpec は、テストケースを入れ子にできたり、テストケースや example がクラスやメソッドではなく、文字列で自由に書くことができたりしたのが良かったのですが、最近の Test::Unit ではそれもできるようになっています。 [ruby-list:48926] [ANN] test-unit 2.5.2 このリリースはとみたさんに使ってもらえるように改良したリリー スです。新しく追加した--locationはRSpecの--line_number
RSpecでPower Assertをやるには
RubyKaigi 2014でpower assertの話を聞いてrspecでどうにかならんかちょっと考えてみました。まず結論だけ書くとrspecでpower assertを使いたければ以下の様に書けばOK。 require 'rspec' require 'minitest' require 'minitest-power_assert' module Minitest module Assertions prepend Minitest::PowerAssert::Assertions end end RSpec.configure do |config| config.expect_with :minitest end describe 'Test' do it 'test' do assert { 1.to_s.class == 1.to_i.class } end end これを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
A Quick Guide to Rails System Tests in RSpec
移動しました - SmartHR Tech Blog
http://blog.inouetakuya.info/entry/2014/11/03/191059
RSpec Performance Turning
