Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

はじめに やりたいこと:カッコよくグリーンを出したい! 「テストは大事!」とは言うものの、どんなRSpecを書いたらいいのかわからない...。 そんな状況が、Railsのお仕事に本格的に関わるようになってから、続いておりました。 そもそも自動テストには憧れがありますし、specを実行して、ターミナルに緑の文字を出したいのはやまやまです。でも、何を書けばいいのかわからない。 そんな時の、とりあえずの取りかかりの例を載せてみます。 ※ この記事の例について: 下記の例は、実際はテストとして無理に書く必要はないものだったりします。 自明なものを書きすぎると、たとえば全てのテストを通すのにも非常に時間がかかってしまいますので、このあたりは、rspecを動かす場合の確認用、1例として見ていただけると幸いです。 ※ これからRspecを始めたい方 / 初心者の方へ (20180523 追記) @jnc
はじめに 2015年6月12日にRSpec 3.3がリリースされました。 APIが大きく変更されたり、派手な新機能が追加されたりはしていませんが、うまく活用するとテストを効率よく書いていけそうな実践的な新機能がたくさん導入されています。 この記事ではそんなRSpec 3.3の新機能を紹介していきます。 新機能一覧 RSpec 3.3で追加された主な新機能は以下の11個です。 これから各新機能の内容を紹介していきます。 特定のエクスペクテーション群をまとめて検証できる(aggregate_failures メソッド) グループやexampleをID指定して実行できる 失敗したテストだけを再実行できる(--only-failures オプション) 失敗したテストを1件ずつ修正できる(--next-failure オプション) テストが増減しても seed を指定したランダム実行が同じ順序で実行
ジョブの実行をテストしたいとき、キューに入ったことをテストしたいだけのときと、その実行結果まで含めてテストしたいとき(つまり同期実行したいとき)がある。 前者であればRails.application.config.active_job.queue_adapter = :testで足りるが、後者を実現するためにはどうすればよいだろう。 方法はいくつかあって、まずはRails.application.config.active_job.queue_adapter = :inlineとする方法。 これは簡単に同期実行は実現できるが、こんどはキューに入ったことが確認できなくなってしまうし、他の非同期のままにしておきたいところまで影響がでてしまう。 またSidekiqを使っているのであればSidekiq::Testing.inline!やSidekiq::Testing.fake! で制御すること
はじめに Travis CI上でMySQLを使う方法を調べたので自分用にメモ。公式サイトと以下のエントリを参考にさせていただきました。この記事ではRubyとRSpecを使っていますが、他の言語やテスティングフレームワークでもほぼ同じだと思います。 https://docs.travis-ci.com/user/database-setup/ http://qiita.com/suzuki86/items/e9682a242cad52003b08 設定手順 Travis CI上でユーザー名root(travisユーザーでも良いが権限がやや制限される)、パスワードなしでログインできる環境が自動的に立ち上がるため、こちら側で必要なのはテスト用データベース、テーブルの作成とdatabase.ymlの設定のみ .travis.ymlの設定 before_scriptに直接SQLを書いてもいいのですが
# インスタンス変数を使う場合 before do @user = User.new(name: 'Taro', email: 'taro@example.com') end it 'is valid' do expect(@user).to be_valid end # letを使う場合 let(:user) { User.new(name: 'Taro', email: 'taro@example.com') } it 'is valid' do expect(user).to be_valid end RSpecを使い慣れている人であれば、おそらくletを使うことが多いと思いますが、初心者の人には違いやメリットがよくわからないと思います。 また、使い慣れている人であっても具体的な違いをぱっと即答できる人は少ないんじゃないでしょうか? ネットを調べていたところ、Stack Overfl
これは Ruby アドベントカレンダー 24 日目の記事です。 Railsを長く開発していると機能を追加していくにつれてテストコードも肥大化し、初めのうちは一瞬で終わっていたrspecも気がつけば数十分かかるようになっていたということも多いと思います。テストをCIで回していると、結果が得られるまで作業が止まることになるので、テスト時間の肥大化は結構大きなインパクトを持ってきます。 テストの中にボトルネックがある場合それを解消することである程度の高速化ができますが、純粋にテストの数が多いということになると、全てのテストを実行するのを諦めないのであれば、テストを並列に実行するのが高速化のアプローチとなります。 テストを並列実行するgem テストを並列に実行するgemはすでに世の中にいくつもあります。 rrrspec Cookpad社が作っているrrrspecはRSpecを複数サーバで分散実行し
shared_examples_for 'test example' do |my_proc| context 'this is context' do it 'hoge' do expect(1).to eq 1 end it 'huga' do expect('1').to eq '1' end module_exec(&my_proc) end end describe 'foo' do include_examples 'test example', proc { it 'foo' do expect('foo').to eq 'foo' end } end describe 'bar' do include_examples 'test example', proc { it 'bar' do expect('bar').to eq 'bar' end } end
何が違うか知らなかった時に調べたメモ。ちなみに Rspec 3 の話。 簡単に言うと以下のとおり。外的な要因で一時的に落ちているけど、いずれ通るようになる example は pending にすれば良いと思われる。(参考資料) pending: example が失敗したらテストは成功になる skip: example は実行されない pending は何らかの事情で example が失敗する原因を修正できない場合に使えば良い。パッチがマージされるまで example が失敗する場合など。そのような時に pending を使っておけば、example が失敗する原因が修正されたときに(pending な example が成功することで)テストが失敗するようになるので、もう pending にしておく必要がないと気づくことができる。あるいは原因不明だけど example が失敗している
Grape は Ruby で API を書くのに便利なフレームワークです。 Grape 自体については fakestarbaby 氏がすでにすてきなエントリを書いてくださっています。 Grape | API生成マイクロフレームワーク #Rails #Gems #Ruby #grape #api_builders - Qiita ここではどうやってテストを書くのかということについて書いてみたいと思います。 想定 RSpec の受け入れテストの request_spec を使うよ API は JSON を返すよ API 用のサブドメイン(api.foobar.com)を切っているよ JSON のテストは json_expressions を使うよ(参考) OAuth 2.0 の Provider になって Web Application Flow とかで認証しちゃったり モックは Factor
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く