Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
はじめに 個人用のメモです。 Railsチュートリアルを完走し、現在、Everyday Rails - RSpecによるRailsテスト入門を用いてRSpecの勉強を進めていたところ、10章にて「モックとスタブ」というものが出てきました。 初見ではあまり理解できなかったため、それぞれの定義や文法などの基本をさらうべくまとめてみました。 モックとスタブの定義・特徴・文法 モック テスト用の影武者として働くオブジェクト。 データベースへのアクセスなしで生成される（＝テストの時短に繋がる）。 doubleを用いて影武者を生成 スタブ テスト用のダミーメソッド。 データベースやネットワークを使うメソッドをデータベースへのアクセスなしで呼び出す。 allow(モデル名).to メソッドを用いてダミーメソッドを作成 使用例 以下の例ではuser = double("user", name: "Fake
業務でrspecを使っているのですが、 rspecは車輪の再発明だと言われたり、 DHHはminitestがおすすめだったり、 minitestのほうが速いと言われていたりする記事を見て、 「なんかminitestのほうが強そうやん」という思いを馳せ、 調べてみたのでご報告でございます。 基本的に、以下２つを参考にいたしました ・RSpecユーザのためのMinitestチュートリアル サンプル ・RSpecとMinitest、使うならどっち？ expect(A).to eq Bはassert_equal B, A 比較は以下になります。 rspecでexpect(A).to eq Bでしたが、 minitestではassert_equal B, Aのようになります。 この違いはrspecの記述がDSL（ドキュメント風）なのに対して、 minitestはピュアRubyであるという違いから生ま
はじめに 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を使うときは、漫然と先人のコードをコピペして、設定をrails_helper.rbに書いたりspec_helper.rbに書いたりしていましたが、「rails_helper.rbにだけ書けばよい」という結論に至りました。 次のStack Overflowの回答を参照。spec_helper.rbは、Railsを読み込まずにRspecだけで何かしらRubyのコードをテストするのに使うらしい。 ruby on rails - How is spec/rails_helper.rb different from spec/spec_helper.rb? Do I need it? - Stack Overflow Rspecが生成するrails_helper.rbのテンプレートの先頭は次のようになってます。まず、spec_helper.rbを読み込み、その後でRails（conf
# インスタンス変数を使う場合 before do @user = User.new(name: 'Taro', email: '[email protected]') end it 'is valid' do expect(@user).to be_valid end # letを使う場合 let(:user) { User.new(name: 'Taro', email: '[email protected]') } it 'is valid' do expect(user).to be_valid end RSpecを使い慣れている人であれば、おそらくletを使うことが多いと思いますが、初心者の人には違いやメリットがよくわからないと思います。 また、使い慣れている人であっても具体的な違いをぱっと即答できる人は少ないんじゃないでしょうか？ ネットを調べていたところ、Stack Overfl
今回は、Ruby on Rails のモデルクラスに対するテストの書き方を解説します。 Customer モデルの仕様 この連載のサンプルアプリケーション Sinope がいったい何を目的とするものなのかまだ決まっていませんが、仮に「顧客（customer）」という概念が必要で、そのために Customer という名前のモデルを用意するものとしましょう。 このモデルの主な仕様は以下の通りです： 姓（family_name）、名（given_name）、姓フリガナ（family_name_kana）、名フリガナ（given_name_kana）が必須入力項目。 それぞれ40文字以内。 姓と名で許される文字の種類は、漢字、ひらがな、カタカナ。 姓フリガナと名フリガナはカタカナのみ。ただし、ひらがなでの入力も受け付けて、カタカナに自動変換する。 いわゆる半角カナは全角カナに自動変換する。 今回は
はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供する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ってわけわからん」となっている人もこの記事で再入門してみると
#はじめに 現在、プログラミングに触れて１ヶ月半ほどになりました。 RSpecで冗長な記述をしたくない。そんなときに使えるのがbeforeです。 今回はbeforeの使い方について自分の理解を深める意味も込めて、説明したいと思います！ #beforeとは？ beforeは とすることでbeforeの後に共通している部分を前もって定義しておくことができます。 #実際に使ってみます。 例えばログインしているユーザーがメッセージを送信できるアプリがあったとして、 コントローラのindexアクションでテストをやってみます。 まず一つが it "テストしたいこと" do end で囲まれる手前で記述する方法です。 下の例をみてください ※説明しやすいようににA~Dで記述しました。また、説明に必要のない記述は全て省いてあります。 describe MessagesController do descr
前提 ruby 2.6.3 Rails 6.0.3.1 rspec-rails (3.9.1) system specのテストを書いていると、テストを走らせてから実行にかなり時間がかかりますよね。 個々のテストは、テスト作成時にピンポイントで行い、全てのテストが全てパスしているかは、リモートリポジトリにpushした時にcircle CIに任せるような、割り振りにしたいと考えました。 てな感じで、個々のテストをピンポイントで走らせたい場合について調べました。 特定のファイルのみテストを走らせる #bundle exec rspec spec/パスを指定する bundle exec rspec spec/system/users_spec.rb
![[rspec] 特定のテストのみ実行する方法 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/776db4ac4dce1a3578729c4018ffbe4ac5b7850e/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCcnNwZWMlNUQlMjAlRTclODklQjklRTUlQUUlOUElRTMlODElQUUlRTMlODMlODYlRTMlODIlQjklRTMlODMlODglRTMlODElQUUlRTMlODElQkYlRTUlQUUlOUYlRTglQTElOEMlRTMlODElOTklRTMlODIlOEIlRTYlOTYlQjklRTYlQjMlOTUmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPTViMWE4ZWY0ZTIxM2I3ZmY1YmY3ZjM2ZTc1NWYxNjZl%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB2aW5ha2EmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWE4YmM3OWY4YjRkYWZiYmMzYmY0NDY2YTA4NDY3NzBk%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D8dd74402bc534e785fa2dc644deef67e)
(2019/11/24) 大人の事情で(だいぶ前に)FactoryGirlがFactoryBotに改名されたので、本記事も更新しました。 単純置換しただけで内容は依然書いた当時のままなので、最新版とは乖離があるかもですご注意ください Railsのテスト環境として人気のあるFactoryBot/RSpecの組み合わせを学習中です。同時に学ばれている方も多いかと思うのですが、混乱しそうなのでFactoryBotだけ先に調べてみました。 概要 FactoryBot = データ(モデルインスタンス)生成のためのライブラリ オープンソース / MITライセンス 柔軟に記述できるため、Rails標準のfixturesの代替として人気 主にテストデータの生成に利用する 導入 Railsの場合はgem factory_bot_rails をインストールする。
コマンドを打つと、.rspec, spec/rails_helper.rb, spec/spec_helper.rbファイルが生成されます。 rails_helper.rbはデフォルトではこのようになっています。 # 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 pro
Rspecとは？ Rspecとは自動テストをしてくれる言語。になります。 UIテストをいちいちせずとも、 「ページの遷移」、「モデルバリデーション」、「if分の条件分岐による処理の確認」... などなど、人間がやるには面倒なことを自動でやってくれるのがRspecになります！ 準備 今回は比較的簡単な、 「コントローラーによる画面遷移確認テスト」 のコードを書いていこうと思います また、ログイン後の処理定義をするコードを書きますが、そのログイン処理をDeviseを使ってやるものとします 導入するGemインストール 今回使うのはRspecとFactory_botというGemを使います 内容については後ほど解説しますので、まずはインストールしましょう！！
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに RSpecは難しい、よくわからない、といったコメントをときどき見かけます。 確かにちょっと独特な構文を持っていますし、機能も結構多いので「難しそう」と感じてしまう気持ちもわかります。 （構文については僕も最初見たときに「うげっ、なんか気持ちわるっ」と思った記憶がありますw） しかし、RSpecに限らずどんなフレームワークでも同じですが、慣れてしまえばスラスラ書けますし、実際僕自身は「RSpecって便利だな－」と思いながらテストコードを書いています。 そこでこの記事では、僕が考える「最低限ここだけを押さえていれば大丈夫！！」なR
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
