はじめに RSpecを書くときに、shoulda-matchersというGemを使うと非常に便利でした。 shoulda-matchersとは Shoulda Matchers provides RSpec- and Minitest-compatible one-liners to test common Rails functionality that, if written by hand, would be much longer, more complex, and error-prone. Shoulda Matchersは、手書きで書くと長くて、複雑で、エラーが起きやすいRailsのテストをワンライナーにします。(意訳) ワンライナーって1行ってことでいいのでしょうか... 使用方法 このようなuserモデルに対し、
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_
こんにちは！メグミです！ 今回は モックを使ったテストの書き方について書きたいと思います！ はじめに 処理の中でジョブを呼んだりする場合があると思いますが、 実際のジョブのテストは別で作成しているので、ジョブが呼ばれたかのテストをしたい！ ということがありました。テストの書き方について理解が曖昧だったので調べてみました！ 基本的な書き方 Articleモデルにtitleメソッドがある場合 allow(article).to receive(:title).and_return("タイトル") allow(実装を置き換えたいオブジェクト).to receive(置き換えたいメソッド名).and_return(返却したい値やオブジェクト) メソッドの引数が1つ以上ある場合 allow(article).to receive(:title).with(argument_1, argument_2
Take very small stepsDon’t rush ahead with more code. Instead, add another example and let it guide you to what you have to do next. And don’t forget to take time to refactor your code before it gets messy. You should keep your code clean at every step of the way. View Documentation The BookEffective Testing with RSpec 3: Build Ruby Apps with ConfidenceThis definitive guide from RSpec’s lead devel
Rails defaults to minitest, but much of the community has adopted RSpec—which is right for you? In this article, William Kennedy compares RSpec and Minitest in a new Rails app. Rails is a framework that comes with nearly everything included, focusing on conventions over configurations. Minitest is one of these conventions. Minitest is small and fast, and it provides many assertions to make tests r
翻訳する目的 Everyday Rails - RSpecによるRailsテスト入門を読み、モック関連と、FactoryBotについて更に知識をつけたいと思いました。どちらも技術本で学ぶのは難しいので、リポジトリのREADMEを通じて学ぶのが良いと考えました。 Google翻訳やDeepLを用いて全文翻訳を行うと、日本語が不自然で読みにくかったので、今後何度も参照することを考えて、自分で翻訳することにしました。 FactoryBotのREADMEの翻訳は既に存在していたので、RSpec MocksのREADMEを翻訳することにしました。 翻訳時のルール Google翻訳やDeepLは利用しない。 わからない単語を辞書で調べるのはOK。 翻訳してみてどうだったか？ 良い点 英語のドキュメントを読む練習になる。 ドキュメントを細部までしっかり読む経験ができる。わからなくても投げ出さない経験がで
概要 Railsで作成されたAPIのテストについてこちらを参考に必要最低限の情報をまとめました。 実際にこちらの記事で作成したAPIに対してテストを書いていきます。 何をテストする？ 適切なAPIはHTTPのレスポンスのステータスコードと実際のデータを含んだレスポンスボディを返します。 よって主にその２つをテストしていきます。 ステータスコード 通常APIによって返されるステータスコードは以下の４つに分類されます。 APIの動きによってこちらのコードと照らし合わせる事でテストします。 200: OK - リクエストは成功し、レスポンスとともに要求に応じた情報が返される。 401: Unauthorized - 認証失敗。認証が必要である。 403: Forbidden - 禁止されている。リソースにアクセスすることを拒否された。 404: Not Found - 未検出。リソースが見つから
Rspec内でテスト対象のControllerのメソッドの戻り値をスタブする - My External Storage
C#では対象インスタンスのメソッドの挙動を変えることは出来ないので、別の手段を探していたのだが、rubyでは出来た。 TL;DR RSpec書いたControllerSpecの中でテスト対象のコントローラのメソッドの戻り値をモックオブジェクトに変えたかった。 ControllerExampleGroupで定義されているcontrollerからテスト中のコントローラインスタンスを操作することが可能 Module: RSpec::Rails::ControllerExampleGroup#controller 前提 rspec-rails (~> 3.0.0.beta2)で確認。 テスト対象のコントローラはこんな感じ。 controllerとallowでメソッドの戻り値をすげ替える allowを使えばメソッドの挙動をすげ替えることが出来る。Railsの場合はcontrollerを使えばテスト対
RailsアプリでRSpecを使うと通常example実行のたびにデータが削除されるようになっているが、これが具体的にどのように行われているかについて。 検証環境は以下の通り。 ruby 2.6.1p33 (2019-01-30 revision 66950) [x86_64-darwin16] rails 5.2.2 rspec 3.8.0 rspec-rails 3.8.2 SQLite 3.16.0 use_transactional_fixtures RailsでRspecを使うとき、 bundle exec rails generate rspec:install を実行して初期設定をすることになると思うが、そのときに spec/rails_helper.rb という設定ファイルも同時に作られる。 このファイルにデフォルトで次のような設定が記載されている。 RSpec.confi
Rspec request specでセッションの読み込み、書き込みを実現してみる 今回はActionDispatch::Requestのsessionメソッドを上書きする形で対応します allow_any_instance_of(ActionDispatch::Request).to receive(:session).and_return({}) RSpec.configure do |config| # ... # テストケース共通の事前処理 config.before(:each) do # let(:rspec_session) で指定された値を セッションの初期値とします session = defined?(rspec_session) ? rspec_session : {} # destroyメソッドを実行してもエラーにならないようにします（必要であれば） session
はじめに CI/CDのサービスとして最近はGitHub Actionsを利用しているのですが、CircleCIと比較した時にRSpecが失敗した時の実行結果が分かりにくいのが不満でした。 そんなストレスを解消するために社内ハッカソンで作った以下のGitHub Actionを紹介します。 RSpec Report · Actions · GitHub Marketplace · GitHub 何が出来るの？ PRイベントの場合は失敗結果がコメントされます。 またコメントされることで同様の内容がメールでも通知されるので、失敗したテストの内容がGitHubにアクセスしなくても把握できるようになります。 PRイベント以外の場合はChecks API経由で通知されます。 使い方 name: Build on: pull_request: jobs: rspec: steps: # RSpec実行の為
Leaner 開発チームの黒曜(@kokuyouwind)です。 AWS Startup Community Conference 2022 に CfP を出したので通ってほしい今日このごろです。 さて、今回は Rubocop 警告の修正で少し手間取った話を書きます。 RSpec/MessageSpies に引っかかったコード あるクラスで「Rails.logger に特定文字列を出力していることを検証したい」というケースがあり、この spec を以下のように書いていました。 # ログを出力するクラス class Hoge def log Rails.logger.info('test message') end end # spec RSpec.describe Hoge do describe 'log' do let(:logger) { instance_double(Active
はじめに 仕事でAuth認証のspecを書く場面があったので、いろいろハマったことも含め簡潔に書いていきたいと思います。 【実行環境】 ・ Rails 5.1.4 ・ RSpec 3.7 ・ Ruby 2.4.3 ざっくり実装の手順 Rspecのセットアップ モックの作成 Controllerの認証テスト 【前提】omniauthのルート設定 複数モデルで実装する方も多いと思うので、 Omniauthの認証処理はAuthenticationsControllerでやるとします。 get "auth/:provider" => "authentications#new", as: :new_authentication get "auth/:provider/callback" => "authentications#create", as: :create_authentication 参
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
CI Test環境を作り直した話 morishitaです。 いこーよは Rails アプリケーションです。 ユニットテストには Rspec を利用しています。 それなりに大きなアプリケーションなので全スペックを実行するにはそれなりに時間がかかります。 ローカルPCで全スペックを実行したことはないのですが、試みて終わるのを待てなくて途中で中断する程度には時間がかかります。 実装中のクラスを中心に部分的に Rspec を実行しながら実装しますが、思わぬところに影響していたりすることもまれにあるので、コードレビューに出す前には全部通しておきたいところです。 以前は Docker コンテナを動的に作ってその中で実行する自作の Web アプリケーションがあって、社内に立てたサーバで動かしていました。 一方で他のプロダクトではすでに CodeBuild で RSpec を実行していました。 tech.
The most common way to run tests in a project is to run rspec in the terminal. This runs tests for all examples in the project. Sometimes, this is not what we want. During development, we don’t want to run the whole test suite every time after a change. Most of us want to run only tests related to changes we’ve made to save time. If you’re new to RSpec, here’s a quick introduction to testing with
RSpec Style Guide
This RSpec style guide outlines the recommended best practices for real-world programmers to write code that can be maintained by other real-world programmers. RuboCop, a static code analyzer (linter) and formatter, has a rubocop-rspec extension, provides a way to enforce the rules outlined in this guide.
RSpec 3.5 has been released!
Sam Phippen, Myron Marston and Jon RoweJul 1, 2016RSpec 3.5 has just been released! Given our commitment to semantic versioning, this should be a trivial upgrade for anyone already using RSpec 3, 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.
環境 Ruby 3.0.2 Rails 6.1.4.1 Structについて Rspecで共通処理concernsのメソッドテストを実行する際はStructを使うとテストできる 下記のようなconcernsがあったとする
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にはテストで毎回同じ処理を書かなくても良いように処理を共通化する shared_context という仕組みがあります。 自分は直近まで知らなかったので、個人的なメモとして投稿します。 注記 サンプルコードは適当に用意したコードなので実在のコードではありません。 やりたいこと 毎回ログイン認証チェックをテストのブロック毎に記載したくないので共通化 やり方 shared_context "キーワード" で処理を共通化！ 呼び出したいところで include_context "キーワード" で呼び出す！ サンプルコード # shared_contextでテストのための前処理を共通化する # この場合 "ログイン状態のUserがアクセスする" がキーワードになる shared_context 'ログイン状態のUserがアクセスする' do before do allow(co
Suppose we have such email: class UserMailer < ApplicationMailer def welcome_email(user) @user = user mail(to: @user.email, subject: 'Welcome') end end That is delivered using default ActiveJob & ActionMailer's method: UserMailer.welcome_email(user).deliver_later. (you also need to set config.active_job.queue_adapter = :sidekiq [or some other adapter] in your application.rb to use deliver_later me
【結論】 ・let/let!はインスタンス変数を定義する際、beforeより分かりやすく記述できる ・beforeはインスタンス変数の定義以外（メソッドの実行など）でも利用することができる ・letは変数が初めて使用された時に評価（遅延評価）され、let!とbeforeはブロック宣言時に評価される。 【目次】 let・let!・beforeの役割について 「let・let!」はインスタンス変数の定義に用いる 「before」はメソッドを実行する際に用いる 「let」と「let!」の実行順の違い 参考情報 《今日の学習進捗（3年以内に10000時間に向けて）》 【本題】 let・let!・beforeの役割について let・let!・beforeは、いずれもRSpecにおいて、各exampleで共通の処理を定義することができます。 これによりそれぞれのテストに同じ記述をする手間が省け、DRY
はじめに CircleCIを使ってSystemSpec(RSpec)とRubocopを走らせてみました。 基礎的な学習から実際に使ったソースコードをまとめたので参考になれば幸いです。 基礎学習 教材： 入門ガイド - CircleCI いまさらだけどCircleCIに入門したので分かりやすくまとめてみた 基本的な使い方を知るために公式で用意されている入門ガイド - CircleCIをやりました。 手を動かしながら学習できて、30分ぐらいで終わるのでおすすめです。 次に、いまさらだけどCircleCIに入門したので分かりやすくまとめてみたを読みました。 こちらの記事は、CircleCIについてかなり詳細に説明されています。 最初にざっくり読んだ後、わからないことがあったらこの記事を読み直していました。 CircleCIの実装 参考文献 公式のCircleCI-Public/circleci-
RSpecの #instance_double と #instance_spy の使い分けについて考察してみた。個人の見解です。 環境・バージョン ruby 2.7.0p0 rspec-mocks 3.9.0 #instance_double と #instance_spy の違い・共通点 Verifying Doubles #instance_double も #instance_spy も、Verifying Double と呼ばれるオブジェクトを返すという共通点がある。 これは何かと言うと、テストダブル対象のインスタンスに存在しないメソッドがスタブされた場合や、引数が異なる形式でメソッドが呼び出された場合にエラーを起こしてくれるという機能を持つオブジェクトである。 一方、#double や #spy が返すオブジェクトにはそういった機能はなく、存在しないメソッドをコールしても良いし、
#composerが複数のsongを持つものとする Rspec.describe Sample do let(:composer) { create(:composer) } let(:composer_song) { create(:song, composer: composer, title: 'きらきら星') } it '〜〜' do expect(composer).to ~~ end end end ここでは、expect(composer).toのcomposer が出てきたタイミングで、letで定義したcomposerがcreateされる、ということになります。遅延評価と言うそうです。 以下のコードでは、テストは失敗します。 #composerが複数のsongを持つものとする Rspec.describe Sample do let(:composer) { create(
RSpecでテストをpendingしたい場合はxから始まるメソッドにリネームするといい - コード日進月歩
こんな機能があるんだという気持ちになったのでメモ 環境 rspec (3.7.0) 使いかた example_spec.rb として以下のスペックを書いてみる 実行すれば以下の結果 require "rspec" describe "DummyTest" do describe "Target" do context "Case1" do it "SuccessA" do expect(true).to be true end it "SuccessB" do expect(true).to be true end end context "Case2" do it "FailedA" do expect(false).to be false end it "FailedB" do expect(false).to be false end end end end $ bundle exe
自身が参加するプロジェクトでは、rubocopの縛りによりallow_any_instance_ofを使用すると警告が出てしまいます。 先延ばしが得意な私は、一旦allow_any_instance_ofで逃げといて後で書き換えよーみたいなことをしてしまっていて、結局あとで調べながら書き直すということを繰り返していました。 そのため改めて記事にすることで「一旦allow_any_instance_ofで逃げる」ということがなくなるかなと思い書いています。 allow_any_instance_ofの書き換え # Avoid stubbing using `allow_any_instance_of`. (convention:RSpec/AnyInstance) # allow_any_instance_ofの使用を回避してね。 before do allow_any_instance_o
初めに 今回は備忘録を兼ねて、circleciの基礎について解説します！ 私と同じようなビギナーの方に向けてできるだけ分かりやすく解説しますので良ければご覧ください。 なお、今回使用するCircleCIのconfig.ymlはリンク先の記事を使用させていただいております。 【circleCI】Railsアプリでgithubと連携してrubocopとrspecテストを走らせる 使用する設定ファイル 今回はcircleciの設定ファイルについての解説ですので、導入方法などについては割愛します。 # Ruby CircleCI 2.0 configuration file # # Check https://circleci.com/docs/2.0/language-ruby/ for more details # version: 2 jobs: build: docker: # speci
リーダブルRSpec（カスタムマッチャー+RSpec::ContextHelper編） - Qiita
読みやすいRSpec書いていますか？ 読みやすいRSpecって何？ 「簡潔でテストケースを見てテスト内容が理解しやすいもの」と考えています ここでのテストケースとは、it/exampleブロックのことを指しています 例題 例えば、Rails製REST APIのRequest Specを書くことを考えてみます コードは正しいか確認していないので、多少間違っていてもお許しください🙇 前提 APIはたくさんある 良くないけど、クエリパラメータのチェックをcontrollerでしているため、テストはRequest Specで行う APIの共通仕様 Server Errorを除き、HTTPステータスコードは必ず200で返す HTTPレスポンスボディはJSON形式で返す 成功時のレスポンス
Shoulda Matchers
describe User do it 'is not valid if its username is the same as another user within the same account' do _existing_user = FactoryBot.create(:user, username: 'johnsmith', account_id: 1 ) user = FactoryBot.build(:user, username: 'johnsmith', account_id: 1 ) expect(user).not_to be_valid end it 'is valid if its username is the same as another user within the same account, but for different case' do _
はじめに今回は、効率的にテストデータを用意する方法についてまとめていきます。具体的には、「Factory Bot」を使用したテストデータについてです。Factory Botの導入方法から始まり、継承やtraint、コールバックの機能に関して説明していきます。最後には「まとめ」としてFactory Botを使用する際の注意点もまとめていきます。 Factory BotとはFactory Botとは、テストのサンプルデータを簡単に作成することができる構文を提供してくれるgemです。Factory Botには様々な機能が存在し、効率的にサンプルデータを用意するのに適しています。 Factory Botのインストールそれでは、Factory Botの導入を行います。Gemfileのテスト・開発環境において、gem ‘factory_bot_rails’の記述を追加しましょう。 group :dev
Factorybot 改善ツール作成失敗と学び/ Factorybot improvement tool creation failure and learning
Factorybot 改善ツール作成失敗と学び/ Factorybot improvement tool creation failure and learning
FakeFSを利用します。 defunkt/fakefs · GitHub Gemfile gem "fakefs", :require => "fakefs/safe"RSpecで FakeFS.activate! File.open('test-file.jpg', 'w') do |f| f.puts('foo') end FakeFS.deactivate! # または FakeFS do File.open('test-file.jpg', 'w') do |f| f.puts('foo') end endのようにfile操作をFakeFS.activate!とFakeFS.deactivate!の間 または、FakeFSdo ... end内に書けば良いです。
【CircleCI】『Unable to find gem rubocop-discourse; is the gem installed? Gem::MissingSpecError』が出てRuboCopが失敗する際の解決方法 - Qiita
【CircleCI】『Unable to find gem rubocop-discourse; is the gem installed? Gem::MissingSpecError』が出てRuboCopが失敗する際の解決方法RailsGemCircleCIRuboCop はじめに 本記事では、CI(RuboCop、RSpec）のみ動作させています。 設定ファイルの細かい説明については、分かりやすい記事がたくさんあるのでそちらにお任せします。 参考にさせていただいた記事↓ 最後に私の.circleci/config.ymlの設定ファイルを参考までに記載します。 CircleCI上でRuboCopがエラーになる CircleCIでRuboCopを動かすと次のようなエラーが発生しました。 Unable to find gem rubocop-discourse; is the gem ins
# This file is copied to spec/ when you run 'rails generate rspec:install' require 'spec_helper' ENV['RAILS_ENV'] ||= 'test' require File.expand_path('../config/environment', __dir__) # Prevent database truncation if the environment is production abort("The Rails environment is running in production mode!") if Rails.env.production? require 'rspec/rails' # Add additional requires below this line. R
1.この記事をなぜ書いたか Rspecを勉強して学んだことをまとめるために書きました。 今すぐRspecの環境構築手順を見たい方は、4章から見ることをオススメします。 記事の中で間違いがある場合、コメント頂けると嬉しいです。 2.そもそもRspecとは何か? Rspecとは、「プログラムの振る舞い」を記述するためのドメイン特化言語(DomainSpecific Language:DSL)を提供するテストフレームワークのことです。 ドメイン特化言語とは、特定のドメイン(問題領域)を記述するために設計された言語です。Rspecの場合、特定のドメインは「開発対象のプログラムの振舞い」を表します。 そして、Rspecが提供するDSLを使用してテストコードを書くことによって、Railsアプリケーションの挙動をテストすることができます。 3.Rspecとminitestの違いとは？ テスト機能を提供す
Setting session variables in an RSpec Rails request spec
rspec_rails_set_session.md Setting session variables in an RSpec Rails request spec You are writing a spec with type: :request, i.e. an integration spec instead of a controller spec. Integration specs are wrappers around Rails' ActionDispatch::IntegrationTest class. I usually write controller tests using this instead of type: :controller, mainly because it exercises more of the request and respons
class Sample def foo(x) ho = hoge(x) do |y| piyo(y) end ho + 'foo' end def hoge(x) yield x + 'hoge' end def piyo(y) y + 'piyo' end end describe Sample do it 'yields block of hoge method by passing block to stub' do allow(subject).to receive(:hoge).with('start') do |x, &block| expect(block.call(x)).to eq('startpiyo') 'startpiyo' end subject.foo('start') end it 'yields block of hoge method by using
ActiveSupport::Testing::TimeHelpers を rspec-rails をロードする前に include すると travel_back が動かない - 暇人じゃない
ActiveSupport::Testing::TimeHelpers の travel_to を使って日時を固定するテストで、 それ以降に実行する他のテストでも日時が固定されたままになっている現象に遭遇した。 # foo_spec.rb describe 'foo' do before { travel_to(Time.zone.now) } # ... end # bar_spec.rb describe 'bar' do # 日時が固定されたまま end
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
shoulda-matchersが便利すぎる - Qiita
【RSpec】モックを使ったテスト | 働くひとと組織の健康を創る iCARE
RSpec: Behaviour Driven Development for Ruby
Minitest vs. RSpec in Rails
RSpec MocksのREADMEを翻訳 - Qiita
【Rails】APIテストの書き方 - Qiita
RSpec with Railsでテスト時のデータはどのように削除されているか
RSpec RequestSpecでsessionを利用する - Qiita
RSpecの実行結果を分かりやすくするGitHub Actionを作った - Qiita
Rubocop の RSpec/MessageSpies に対応する際は処理順の書き換えが必要
【OmniAuth + Devise】Twitterのログイン認証をテストする方法【Rspec】 - Qiita
GitHub - asonas/rspec-daemon
CI Test環境を作り直した話 - アクトインディ開発者ブログ
RSpec Tutorial: 7 Ways To Run Specific RSpec Tests
【Rspec】共通処理concernsのテストはStructを使うといい - Qiita
RSpec expect の () と {} の違い - Garbage in, gospel out
RSpecのshared_contextで共通処理を1ヶ所にまとめる - カクカクしかじか
How to test ActionMailer + ActiveJob with Rspec (Example)
「let・let!・before」の違いと実行順序（RSpec） - ryotaku's Tech Blog
CircleCIでSystemSpec(RSpec)とRubocopを走らせる - Qiita
instance_doubleとinstance_spyの使い分け
rspec 「let」と「let!」の違い - Qiita
allow_any_instance_ofを使うとRubocopに怒られる理由
circleciに入門したので設定ファイルを解説する。 - Qiita
【Rspec】Factory Botで効率的にテストデータを用意する
RSpecでfileのモックを作成する - nafuruby’s diary
【RSpec】spec/rails_helper.rbを和訳&補足してみた - Qiita
【Rails】Rspecの環境構築手順をざっくりまとめてみた
ブロックの中身をテストするときのRSpecの書き方 - Qiita