RSpec MocksのREADMEを翻訳 - Qiita
翻訳する目的 Everyday Rails - RSpecによるRailsテスト入門を読み、モック関連と、FactoryBotについて更に知識をつけたいと思いました。どちらも技術本で学ぶのは難しいので、リポジトリのREADMEを通じて学ぶのが良いと考えました。 Google翻訳やDeepLを用いて全文翻訳を行うと、日本語が不自然で読みにくかったので、今後何度も参照することを考えて、自分で翻訳することにしました。 FactoryBotのREADMEの翻訳は既に存在していたので、RSpec MocksのREADMEを翻訳することにしました。 翻訳時のルール Google翻訳やDeepLは利用しない。 わからない単語を辞書で調べるのはOK。 翻訳してみてどうだったか？ 良い点 英語のドキュメントを読む練習になる。 ドキュメントを細部までしっかり読む経験ができる。わからなくても投げ出さない経験がで
rspec-mocksを使ってテストで上手に手を抜こう
対象 RSpec での簡単なテストの書き方は基本的に知っている rspec-mocks を使ったテストを知らない|知ってるけど雰囲気で使っている 上記に当てはまる私自身が、テストをより効率的に書くために、広く浅くざっくり調べた内容のため、より詳しく知りたい人は公式ドキュメントなどを漁ってください。 ※記事中に出てくるコードの多くは、RSpec によるテストコード内で実行されるコードです。周辺のコードは省略するので、適当に文脈から読み取ってください。 前提 rspec-core (3.7.1) rspec-mocks (3.7.0) rspec-rails (3.7.2) rspec-support (3.7.1) rspec-mocksとは rspec-mocksは、RSpec用のテストダブルフレームワークで、モックとかスタブとかスパイとかサポートしてくれます。 テストダブルとは、テスト対
RspecでMockを使う - Qiita
記述例は、全てitの中で書かれているものとして読んでください。 letやsubjectに分離して記述する場合は、適宜読み替えてください。 いいね、つけていただいたんで情報足します。 20170119 mockを使ったrspecテストのコツ はまって試行錯誤した結果のまとめ。 publicメソッドのテストに注力する privateメソッドはテストしない方向で 他のメソッドが呼ばれる箇所はそのメソッドを偽装し、他のメソッドをテストするようなことにならないようにする 他のクラスのインスタンス生成箇所は、元のコードの方をプライベートメソッド化し、偽装 他のクラスのインスタンス生成箇所はインスタンス変数に入れて後で使うことが多いので上記のメソッド偽装して、インスタンス生成部分をスキップ。インスタンス変数をinstance_variable_setで直接spec上で突っ込む メソッド内でインスタンス変
RSpec における double / spy / instance_double / class_double のそれぞれの違いについて - Qiita
RSpec における double / spy / instance_double / class_double のそれぞれの違いについてRubyRSpec はじめに RSpec でモックを作る際の double、spy、instance_double、class_double のそれぞれの違いについて説明します。 TL;DR double と比較した際に spy は呼び出されるすべてのメソッドを明示的にスタブする必要がない instance_double は未定義のインスタンスメソッドをスタブしようとした際にエラーになる class_double は未定義のクラスメソッドをスタブしようとした際にエラーになる
rspecを読みやすくメンテしやすく書くために
はじめに 読みやすくメンテナンスしやすいRSpecを書けていますか？ RSpecはというかRubyはというか柔軟なので色々な書き方ができてしまいます。 ある程度の規模のテストコードでは、油断するとどこで定義されている let なのかわからないものが登場したり、なぜか作られる（あるいは作られない）謎のレコードでテストが失敗したり、そういった辛い目にあったりするのではないでしょうか。 僕がRSpecを書くときに意識していることをまとめてみました。 これを実践するようになってつらい現象にあうことはずいぶんと減り、ずいぶんと読みやすくなったんじゃないかなと思っています。 ※効果には個人差があります。 Ruby on Railsを使ったアプリケーションのテスト向けですがRuby on Rails以外でも使えると思います。 主に以下の影響を強く受けています。 RSpecとセットで使われることが多いFa
rspecでモックを使うときに気をつけていること
スタブとは テストコード内で利用されるもの。 テスト対象のメソッドや処理から、別のメソッドを介してデータを取得したり加工したりする場合に、決まりきった値を返すように設定したものを指す。 class A def initialize @b = B.new end def hoge ... @b.fuga ... end end A#hoge のユニットテストを書く場合に、B#fuga の細かい挙動については知る必要がなく、A#hoge のテストをするに当たって都合のいい値さえ返してくれればいい。(もちろん B#fuga 別途ユニットテストを書く必要がある。) テストを記述する際に、そのテストで確認したい内容のために何か都合のいい値を返すように設定したものがスタブである。 モックとは モックもテストコード内で利用されるもの。 あるメソッドを呼び出す際に、その引数や呼びされる回数を検証するために
【RSpec】モックを使ったテスト | 働くひとと組織の健康を創る iCARE
こんにちは！メグミです！ 今回は モックを使ったテストの書き方について書きたいと思います！ はじめに 処理の中でジョブを呼んだりする場合があると思いますが、 実際のジョブのテストは別で作成しているので、ジョブが呼ばれたかのテストをしたい！ ということがありました。テストの書き方について理解が曖昧だったので調べてみました！ 基本的な書き方 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
RSpecで引数に特定の値が渡された時だけスタブしたい - ESM アジャイル事業部 開発者ブログ
はじめに こんにちは。入社して4年目になりました、wai-doi です。 お仕事でRSpecでテストを書いていて、 「引数に特定の値が渡された時だけスタブしたい」 ということがありました。そのときどのように書けばよいか分からなかったので、今回は調べたこととその方法を書きます。 実行環境 Ruby 3.1.2 RSpec 3.11.0 サンプルコード 例えば以下の Shopper#buy_fruits メソッドのテストをしたいとします。単純に配列の ['apple', 'banana', 'orange'] を返します。 class Shopper def buy_fruits(shop) basket = [] basket << shop.sell('apple') basket << shop.sell('banana') basket << shop.sell('orange') b
【RSpec】described_classについて - Qiita
はじめに RSpecを書くときに、described_classを使うようにアドバイスをいただきました。 今回は、described_classの使い方と使う理由を説明していきます。 described_classの使い方 通常、このようにモデルの処理を書くと思います。
使えるRSpec入門・その3「ゼロからわかるモック（mock）を使ったテストの書き方」 - Qiita
はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第3回です。 今回はRSpecのモックを使ったテストについて説明します。 これまでモックを全く使ったことがない人でもわかるように丁寧に説明していくつもりです。 また、これまでの回と同様、個人的に使用頻度が低いと思っている内容についてはバッサリ説明を省きます。 ただし、第1回や第2回に比べるとテストコードが少し複雑になって、仕組みや動きを想像するのがちょっと難しいかもしれません。 ぱっと頭に入ってこない場合はじっくり本文を読んだり、実際に自分で写経しながらコードを動かしたりするなどして、少し時間をかけながら理解するようにしてください。 今回は以下のような内容を説明します。 モックの基本的な使い方 モックを使った検証 モックでわざとエラーを発生させ
自動テストはなぜうまくいかないか？乗り越えるためには何が必要か？ - Qiita
リファクタリングの鶏卵問題 ソースコードがクソなので綺麗にしたい。 リファクタリングしたい。 しかし、リファクタリングが出来ない。 リファクタリングが出来ないのは、テストが無いからだ。 よし。じゃあテストを書こう。あれ、テストが書けない？ そのようなテストが無く、書き換えられないことによる矛盾や憤りは皆さん何百回と感じてきたと思います。 しかし、この「テストが出来ない」ということを言語化するのは、非常に難しいと思います。それは、「テストが出来ない」には実は2つの視点があります。 本質的にテストが困難なモジュールで、誰がやってもテストが書けない。 本質的にモジュールはテスト可能だが、自分の実力が足りず、自分ではテストが書けない。 1.のようなテスト困難なモジュールは誰がやってもテストは書けないです。しかし、問題は、「テストを書きたい」と思ったとき、「自分がそれほどテストに詳しくない」という場
RailsでDBと連携しないModelを作成する - Qiita
概要 RailsのModelは、通常DBと結びついていないと使えないが、 データソースをDBではなく外部APIなどに変更し、 validation機能はそのまま使いたい。 ActiveModel::ModelをMixInしてvalidation機能を有効にし、 callbackでvalidateすることで実現する。 環境 rails 5.0.0.1 ruby 2.3.1 ソースコード例 ActiveModel::ModelをMixIn これで通常のModelと同様にvalidate機能を利用できる。 自作validationも使えるようになる。 class Sample # MixIn include ActiveModel::Model attr_accessor :name, :email, :age # before_saveを使うための記述 define_model_callbac
使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」 - Qiita
はじめに RSpecは難しい、よくわからない、といったコメントをときどき見かけます。 確かにちょっと独特な構文を持っていますし、機能も結構多いので「難しそう」と感じてしまう気持ちもわかります。 （構文については僕も最初見たときに「うげっ、なんか気持ちわるっ」と思った記憶がありますw） しかし、RSpecに限らずどんなフレームワークでも同じですが、慣れてしまえばスラスラ書けますし、実際僕自身は「RSpecって便利だな－」と思いながらテストコードを書いています。 そこでこの記事では、僕が考える「最低限ここだけを押さえていれば大丈夫！！」なRSpecの構文や、僕が普段よく使う便利な機能をまとめてみます。 具体的には以下のような構文や機能です。 describe / it / expect の役割 ネストした describe context の使い方 before の使い方 let / let!
Rails: RSpecをもっとDRYに書くテクニック（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Small steps to DRYer RSpec 原文公開日: 2017/01/22 著者: Victor Shepelev-- ウクライナ在住のRubyプログラマーで、SciRubyのメンテナーとメンターでもあります。 2017/11/29: 初版公開 2023/07/11: 更新 🔗 これは何？ RSpec APIは可能な限りDRYで読みやすいDSLへと絶え間なく進化し続けています。しかし、specをさらにDRYにできる方法（トリックや追加メソッドなど）はまだまだあるのです。 警告: 本記事を読んで「この方法を使うより先に、テストしやすいコードを書けるように設計を見直す方がいいのでは？」と言いたくてたまらなくなるかもしれませんが、そうした方法は既に知られているとお考えください。 更新情報（2017/08/15）: sah
僕がRSpecでsubjectを使わない理由 - give IT a try
はじめに 僕は折に触れて「RSpecではなるべくsubjectを使わない方がいい」という発言をしています。 Qiitaとか見てるとRSpecのsubjectを愛用している人が多そうな印象なんだけど、僕はほとんど使っていません。「subjectは原則使わない。明らかにメリットがあるときにだけ例外的に使用する」が僕のポリシーです。ほら、RSpecの（元）メンテナさんもそう言ってるし。 https://t.co/Rp5EiIxCVb #Qiita pic.twitter.com/pMlN35ihEG— Junichi Ito (伊藤淳一) (@jnchito) 2019年5月28日 そもそもの話として、RSpecではsubjectは無理に使わない、というのが僕の持論です。なぜなら無理にを使うと、いびつなテストコードができやすいから。基本はsubjectなしで書く。明らかにsubjectが有効なと
RSpecでヘルパーメソッドを定義する - Qiita
複数のテストケースで共通する処理を別メソッドに置きたい場合、以下のようにヘルパーメソッドを定義する事ができる。 describe “a test group” do def my_helper_method :available end it “has access to methods defined in its group” do expect(my_helper_method).to be(:available) end end メソッドのスコープはグループ内 子グループは親グループのメソッドを使用できるが、親は子のメソッドを参照できない。 参照： https://www.relishapp.com/rspec/rspec-core/docs/helper-methods/arbitrary-helper-methods 他にも module にhelperメソッドを定義する方法も
helperのRSpecの書き方 - Qiita
helperのテストの書き方を忘れるので、備忘録として投稿します。 以下のようにhelperに簡単なメソッドを用意して、テストを書いてみます。 helloというメソッドを実行すると、'hello'という文字列が返ってくる簡単なメソッドです。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - willnet/rspec-style-guide: 可読性の高いテストコードを書くためのお作法集
【Rspec】共通処理concernsのテストはStructを使うといい - Qiita
RSpec 入門 - HackMD