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! で制御すること
# インスタンス変数を使う場合 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
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
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
(2014/12/12 追記) 本稿のアップデート版みたいなのをアップしました→『【Rails】RSpecと三種の神器でらくちんWeb APIテスト - Qiita』 Railsアプリを作るときに,Web APIのテストをしようとしたら命を落としかけたのでいろいろヤバそうなところをメモっておきますφ(`д´) JSONレスポンスのテストはすべき? **Everyday Rails - RSpecによるRailsテスト入門**では,Viewのテストは取り扱っていません(理由は2章 Q&Aにて). でもWeb APIのレスポンスはどうなんだろう? ということで訳者のひとりである西脇.rbの@jnchitoさんに聞いてみたところ,次のように答えていただきました. @izumin5210 するべきかどうかはケースバイケースです・・・っていうと回答にならないので、yes/noで答えるならyesかな~
<h2>Sign up</h2> <%= form_for(resource, as: resource_name, url: registration_path(resource_name)) do |f| %> (省略)... <% if f.object.password_required? %> <div class="field"> <%= f.label :password %> <% if @validatable %> <em>(<%= @minimum_password_length %> characters minimum)</em> <% end %><br /> <%= f.password_field :password, autocomplete: "off" %> </div> <div class="field"> <%= f.label :passwor
はじめに みなさんこんにちは! この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第4回です。 今回はCapybaraを使ったフィーチャスペックについて説明します。 ただし、今までの記事とは異なり、フィーチャスペックのイロハよりも「Capybaraの使い方」に重点を置きます。 なぜなら、僕個人の経験からいって、フィーチャスペックで困るのは「このブラウザの操作って、どうやってコードで表現するの??」というケースが大半だからです。 それ以外は第1回~第3回の内容をそのまま応用できるので、特に「フィーチャスペックだから困る」ということはないと思います。 今回は説明する主な項目は以下の通りです。 フィーチャスペックの基本 ページの移動や画面のクリック、フォームの操作など 画面やフォームの検証 画面の操作や検証の応用テクニック その他
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く