初めまして、takanekoと申します。 入社して以来2年くらい「ブログ書きます!」と言いつつすっぽかし続けたダメWebエンジニアです。 RSpecえかきうた? 「ぼくのあーるすぺっくのかきじゅん」(僕のRSpecの書き順)です。 RSpecの書き方わからない、という方のために、0から書き上げる際の参考になればと思い書きました。 Specを書き始めましょう RSpecにはModel Spec、Feature Spec、Request Spec、System Specなど色々種類がありますが、今回はRequest Specを書いていきます。APIとかのテストをする際に使うSpecです。 書き順がメイントピックなので、細かい実装の妥当性とかは無視して、以下のような簡単な仕様のユーザ登録APIでSpecを書きたいと思います。 API仕様 URL POST /users(format: :json
RSpec の expect において expect() expect {} はそれぞれ値を引数として取得するか、ブロックつきメソッドを引数とするかが異なります。 expect() これにより、expect() ではすでに取得済みのレコードがあり、それが予期する値と等しいかどうかなどをTESTする際に便利です。 expect(response).to be_success expect(response.status).to eq(200) expect {} 一方 expect {} はexpect実行時に評価される関数を渡すことができるため、例えば Request spec を書くときなどに request 実行をブロックつきメソッドにして呼び出し時に実行したいというときに便利です。 let(:request) { post foobar_path, request_params, r
はじめに みなさんこんにちは! この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第2回です。 今回はRSpecのマッチャについて説明していきます。 第1回と同様、今回も「最低限これだけは」という内容に絞り込んで説明します。 使用頻度の少ないマイナーなマッチャ(注:僕基準)については説明しません。 具体的な項目は以下の通りです。 マッチャとは何か to / not_to / to_not eq be be_xxx be_truthy / be_falsey change + from / to / by 配列 + include raise_error be_within + of これからRSpecを始める人はもちろん、何度かRSpecに触れて「うーん、RSpecってわけわからん」となっている人もこの記事で再入門してみると
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く