Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ※間違いなどございましたらご指摘いただけると幸いです ※随時更新予定 概要 以下、https://semaphoreci.com/community/tutorials/getting-started-with-rspec より引用 RSpec is a testing tool for Ruby, created for behavior-driven development (BDD). It is the most frequently used testing library for Ruby in production app
![[作成中]RSpecについて初学者段階のメモ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/36102e6158693129b63eb357e28fa96f4e28a81a/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFwLW5vcnRoZWFzdC0xLmFtYXpvbmF3cy5jb20lMkYwJTJGMzUxODcxNCUyRnByb2ZpbGUtaW1hZ2VzJTJGMTcxMjU4MzEyOD9peGxpYj1yYi00LjAuMCZhcj0xJTNBMSZmaXQ9Y3JvcCZtYXNrPWVsbGlwc2UmZm09cG5nMzImcz1hNDZmY2ZkNWFiODM0YTJiMmRlNjBhNDk2ZTA1NWIzMw%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253D592c437378f3a8fc9c528bf0f8cf8ad9%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JTVCJUU0JUJEJTlDJUU2JTg4JTkwJUU0JUI4JUFEJTVEUlNwZWMlRTMlODElQUIlRTMlODElQTQlRTMlODElODQlRTMlODElQTYlRTUlODglOUQlRTUlQUQlQTYlRTglODAlODUlRTYlQUUlQjUlRTklOUElOEUlRTMlODElQUUlRTMlODMlQTElRTMlODMlQTImdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtcGFkPTAmcz1hYWEyZTA5ZTNhZDFhMTM4ZmJlZjNiN2I0ODA0MWFiMQ%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBuYWthZDExOSZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1wYWQ9MCZzPTlmYjQ3ZDQ5ZGI5OTQ3N2ZhY2VhYTE1NDFiZWRlNzBl%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3D8fae04da817921e4c02b566eaa9cd452)
INSTANTROOM株式会社（本社：東京都渋谷区、代表取締役：曽根弘介）が運営する、フリーランスエンジニア・ITフリーランスの案件検索サイト「フリーランスボード（https://freelance-board.com/）」は2024年4月のフリーランス案件の単価における市場動向の調査結果を発表いたします。 ◆数字で見る「フリーランス市場動向」 フリーランスボードでは2024年4月30日時点の111,626件の掲載案件を対象に開発言語・フレームワーク・職種別の月額平均単価を調査いたしました。 ■フリーランス案件の月額平均単価 2024年4月のフリーランス案件の月額平均単価は71.0万円、最高単価は280万円です。 ▼掲載中のフリーランス案件はコチラから https://freelance-board.com/jobs ■開発言語別の月額平均単価 開発言語別の月額平均単価は上表の結果となりま
こんにちは、サーバーサイドグループの五十嵐です。 今年の４月に弊社に転職して初めて技術ブログを書きます。 今回はAPIドキュメントの作成ツールとしてGemrspec-openapiを導入した話について書いてみます。 弊社では以前からOpenAPIを導入しドキュメント管理を行なってきました。 しかし、OpenAPIを導入する前からあったAPIに対するドキュメントは不足していたり内容が不十分なものもありました。 このようなツールは導入当初はモチベーションが高くても、年月が経つ内にモチベーションが低下したり、メンバーが変わることで存在自体なかったことになったりはよくあることだと思います。 実際にOpenAPIは全て手で書こうとするとはっきり言って非常にめんどうで、そこそこ工数もかかります。 API新規作成時は自分で必要な情報がわかっているので書きやすいですが、既存のAPIで新しくドキュメントを作
RSpecを結構書いてますが、テストを書く上で、FactoryBotが整備されていると楽ですよね。 ただ、最低限でも過剰でも、テストケースが漏れたりします。 また、無駄にINSERTされて、テストが遅くなったりする事もあります。 改めて整理する為に、こう書くのが良いだろうと思うベストプラクティス！？をまとめてみました。 単体で作成できるように作る 必須項目は全て埋める。できるだけユニークな値となるように 必須のリレーションはassociationで作成する 任意項目もできるだけ埋める traitでベースのfactoryを上書きして共通化する traitをfactory間で共有して共通化する 最後に（まとめ） 単体で作成できるように作る これは基本だと思います。rails cで、一時的に作りたい場合にも役立ちます。 必須項目は全て埋める。できるだけユニークな値となるように Request S
【RSpec】コードの重複を回避することができるit_behaves_likeメソッドの使い方について解説｜TechTechMedia
it_behaves_likeメソッドとはit_behaves_likeメソッドとは、shared_examplesと組み合わせることでテストケースを自在に埋め込むことができるメソッドです。また、it_behaves_likeメソッドは新しいcontextを生成し、そこにテストコードを埋め込む形になります。 使い方では実際に使い方を見てみます。 it_behaves_likeメソッドとshared_examplesは以下のように使用することができます。 RSpec.describe User, type: :model do RSpec.shared_examples 'validation' do it '必須であること' do expect(user.errors[:name]).to eq(['を入力してください']) end end describe 'Hoge' do let(:
手順 1.rails_helperを編集 2.supportディレクトリにてファイルを作成 3.login機能の記入 4.メソッド使用例 1.rails_helperを編集 Dir[Rails.root.join('spec', 'support', '**', '*.rb')].sort.each { |f| require f } # 23行目のコメントアウトを外す ---省略--- RSpec.configure do |config| # 中略 config.include LoginSupport end ('spec', 'support', '**', '*.rb') spec/support/◯◯/△△.rbのファイルを読み込むという設定。 RSpec.configure do |config|下に作成したファイルを読み込むという記述をする。 今回はLoginSupport
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
subject(:actual_object) { ... } it { is_expected.to eq(expected_object) } と subject(:actual_object) { ... } it { expect(actual_object).to eq(expected_object) } では挙動が異なるという話 上の方を actual_object と expected_object を同じ属性などを定義した状態で比較しようとすると、 Compared using equal?, which compares object identity, but expected and actual are not the same object. Use expect(actual).to eq(expected) if you don't care about o
Rubyテスティングフレームワークminitest、test-unit、rspecにおける、法則性を持たない（ランダムな）テスト順序実現方法
テスト同士は独立して相互に影響を与えない（Independent である）ことが望ましいが、作成者が意図せず依存関係を持ちこんでしまう場合がある。 テストの順序を入れ替えると独立していないテストが発見しやすくなるため、テスティングライブラリにはテストの順序を入れ替える仕組みを備えたものが多い。また、順序を都度ユーザー側で指定するのは面倒なので、法則性を持たない（ランダムな）順序でテストを実行する機能を備えている場合もある。 加えて、法則性を持たない順序で実行したテスト失敗をきっかけに依存関係を発見した場合、その後に同じ順序でのテスト実行ができると修正が意図通りに行えたか確認が容易になる。一部のライブラリは、ランダムさを得るための初期値（Seed）を実行時に設定することで、法則性を持たないが、同じ順序でのテスト再実施が可能になる仕組みを備えている。 Ruby で利用されることの多い[1]テス
Rspecを用いてRailsでテストを書いてみたのでそれの備忘録。 テストについてもよくわかっていなかったのでまとめてみた。 テストについて テストは大きく分けて下記の三つである。 ユニットテスト ファンクションテスト インテグレーションテスト ユニットテスト(単体テスト) プログラムを構成するできるだけ小さい単位(ユニット)の機能に対して正しく動作するかどうかを検証するテスト。 関数やメソッドに対して行われることが多く、関数やメソッドのバグを取り除く目的がある。 railsの場合ではモデルに対して行うテスト。 ファンクションテスト(機能テスト) システム開発の際に行われるテストのうち、ユーザー側から要求された機能をシステムが満足しているかどうかを検証するテスト。 ユーザーから渡されたデータと処理の結果を比較するブラックボックステストなど中でどんな処理をされてるかなどのテストというよりは要
#Rails + #rspec でハッシュに対して一部のkey/valueの型だけを検証する、ゆるいテストをするには include と b
expect(a: 1, b: Time.now, c: 'wow').to include({a: be_a(Integer)}) # => true expect(a: 1, b: Time.now, c: 'wow').to include({b: be_a(Time)}) # => true expect(a: 1, b: Time.now, c: 'wow').to include({c: be_a(String)}) # => true expect(a: 1, b: Time.now, c: 'wow').to include({c: be_a(Integer)}) # => [#<RSpec::Expectations::ExpectationNotMetError: expected {:a => 1, :b => 2019-12-13 02:08:55.28392210
[RSpec] example 内で、describe / context / it などを取得する方法 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
![[RSpec] example 内で、describe / context / it などを取得する方法 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/012b6b67d0bf869f47ce34f5ffc2d1e3d7dfd151/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnMzLWFwLW5vcnRoZWFzdC0xLmFtYXpvbmF3cy5jb20lMkZxaWl0YS1pbWFnZS1zdG9yZSUyRjAlMkY0NTgyMiUyRjZhNmZkNzk1YTdhYzBlZjQ0ZmU1OGY2OTdiY2UwNzczYzc4MzBjMTAlMkZ4X2xhcmdlLnBuZyUzRjE2MTg3MjkwMTQ_aXhsaWI9cmItNC4wLjAmYXI9MSUzQTEmZml0PWNyb3AmbWFzaz1lbGxpcHNlJmZtPXBuZzMyJnM9Y2ExYzEwNTQxMjZmZTZjYzljMzViZjkyYmVhYjA1YmM%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253D0d8a81c4edac1f64e5a019b88794a93c%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JTVCUlNwZWMlNUQlMjBleGFtcGxlJTIwJUU1JTg2JTg1JUUzJTgxJUE3JUUzJTgwJTgxZGVzY3JpYmUlMjAlMkYlMjBjb250ZXh0JTIwJTJGJTIwaXQlMjAlRTMlODElQUElRTMlODElQTklRTMlODIlOTIlRTUlOEYlOTYlRTUlQkUlOTclRTMlODElOTklRTMlODIlOEIlRTYlOTYlQjklRTYlQjMlOTUmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtcGFkPTAmcz01NzRlNjEwNGE2MjE2NTAzYWNjOTAyMGUzY2VmODQxMg%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBtb2NoaXp1a2lrb3Rhcm8mdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtcGFkPTAmcz02MDQ3MTU1ZmYwYTA3ODk4MTg2M2E2NmI0YTQwYWI5Yw%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3Da857ecc8bd523be094836a72e872be61)
Rspecとは？ Rspecとは自動テストをしてくれる言語。になります。 UIテストをいちいちせずとも、 「ページの遷移」、「モデルバリデーション」、「if分の条件分岐による処理の確認」... などなど、人間がやるには面倒なことを自動でやってくれるのがRspecになります！ 準備 今回は比較的簡単な、 「コントローラーによる画面遷移確認テスト」 のコードを書いていこうと思います また、ログイン後の処理定義をするコードを書きますが、そのログイン処理をDeviseを使ってやるものとします 導入するGemインストール 今回使うのはRspecとFactory_botというGemを使います 内容については後ほど解説しますので、まずはインストールしましょう！！
【Ruby on Rails】RSpecのdescribe/context/itの意味を理解した件 - Qiita
RSpecを書くときに、describeとかitの意味を理解していなかった。 そこでdescribe、context、itに何を記述すればいいのか？を考えながらRSpec書いたら、まじでみやすくなった。 なので、describe、context、itの意味を備忘録的に本当に最低限まとめておく。
テストコードを書くのがツラくならないようにFactoryBotにLintを導入する | Trial and Spiral
プロダクトが大きくなると当然modelも増えていき、それに伴いアソシエーションも増えたりして、テストの時に必要なデータを作るのが大変になってきます。 RailsとRSpecではFactoryBotというGemでテストデータを作るのがデファクトスタンダードですが、油断すると関連データが複雑に絡みあい、ツラくなります。 今回はFactoryBotによるテストデータ作成をLintで担保して、一定の秩序を得ようというお話。 概要プロダクトが大きくなるとテストデータの準備がたいへんFactoryBotを使ってもまだ複雑で、書くのがツラくなってくるデータ作成をLintで担保して一定の秩序を得ようFactoryBot is何？FactoryBotはRubyのGemで、DSLによる設定を提供し、簡単にデータを作成できます。これによりテスト用のテストデータを楽につくることができます。Rails, RSpec
はじめに RSpecを書き始めてから、describeとcontextに何を書いたらよいか迷うことがありました。なので、describe、context、itの使い分けについて紹介します。 テストの流れ テストの流れは、 テストの対象に対して 特定の条件において 期待するアウトプットが返ってくるかを調べる が主な流れである。 実は、この流れが使い分けのポイントである。 describeはテストの対象を記述 contextは特定の条件を記述 itはアウトプットを記述 となる。 例（モデルのバリデーションテスト） RSpec.describe Task, type: :model do describe 'Taskモデル（テストの対象）' do context '値を入れなくてはならないカラムのバリデーションが有効であるか確認する（条件）' do it '全ての属性の値があれば有効' do t
Capybara でホスト名を動的に書き換えてテストをしたい場合 | Basicinc Enjoy Hacking!
Capybara + Rspec でホスト名を動的に書き換えながらテストをしていきたい場合、どのようにするかのメモ。 /etc/hosts を修正するわけにもいかないし…と路頭に迷っていたらインフラに強いメンバー 306 がアドバイスくれました。ありがとう。 ホスト名の最後に .localhost をつける これだけです。こうすればホスト名がなんであろうと 127.0.0.1 のローカルを参照してくれます。最高。 Capybara.app_host でアクセス先のホストを設定できる。ついでにポートも動的になっているのを合わせておく。 RSpec.describe 'Hoge', type: :system, js: true do let(:port) { Capybara.current_session.server.port } it do Capybara.app_host = "h
Rails 5.2.4.1 にアップグレード後、bundle exec rspec で実行できるテストが bin/rails spec で実行できなくなりました。 Rubymine に設定していた Run rake task の設定も同様でしたので調査。 CLI での実行bin/rspec が公式に書かれているので、これを設定していきます。 rspec/rspec-rails: RSpec for Rails-3+bin/rspec は存在しません。
RSpecの feature spec で href の無い a タグのテストをしようとしてハマったのでメモ ボタン / リンクの存在 ボタン button や submit <button>ボタンのラベル</button> <input type="submit" value="ボタンのラベル" /> expect(page).to have_button 'ボタンのラベル' リンク a タグはボタンではなくリンクでないとマッチしない <a href="example">リンクテキスト</a> expect(page).to have_link 'リンクテキスト' リンク先 (href) も含めてマッチ expect(page).to have_link 'リンクテキスト', href: 'example' ボタン / リンクのクリック Capybara でクリックさせる ボタン but
Lint/AmbiguousBlockAssociation 公式の例を見てみます。 bad の例だと、block が a に対してか、 some_method に対してかがわからない。そのため () をつけてわかりやすくするルールです。 # good # With parentheses, there's no ambiguity. some_method(a { |val| puts val }) # or (different meaning) some_method(a) { |val| puts val } # good # Operator methods require no disambiguation foo == bar { |b| b.baz } # good # Lambda arguments require no disambiguation foo = ->(
Capybaraはわりと万能だが、「別にそこまでやってくれなくていい」というところが多い。 Capybaraを最小限使ってラクする方法は↑の記事で書いたが、完全にCapybaraなしでRailsアプリをブラウザと対向させて試験する方法も調べたのでメモ。 Capybaraなしとはどういう状態か 基本的には、以下の3点以外は変わらない。 テストサーバーは起動しない Capybara::DSLがincludeされない visitなどは未実装の例外(NotImplementedError)ではなく、未定義(NameErrorあるいはNoMethodError)になる。 system specはSystemTestCaseがCapybaraに強く依存しているので、使えない たとえばrspec-railsは以下のようなセットアップをしてくれるが、これはCapybaraの有無に関係なく行われる。 spe
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
Kaigi on Rails 2024
Talk 約9000個の自動テストの時間を50分から10分に短縮、偽陽性率(Flakyテスト)を1%以下に抑えるまでの道のり 弊社の Rails アプリケーションは、7年間の開発を経て、自動テストの数が8871個、CIにかかる時間が50分、偽陽性(Flaky)によってCIが失敗する確率が15%という状況でした。 この状況から、CIの高速化 & 安定化のチームを発足し、CIの時間を10分、失敗率は1%程度と、大幅な改善を達成しました。 本セッションでは、この道のりを振り返り、以下のような観点から知見をお話しします。 CI・自動テストに関する根本課題の整理 改善に寄与した施策とその寄与度 効果がなかった施策とその理由 全員が機能開発を続けながら、サイドプロジェクトとして改善を達成するための工夫
はじめに 僕は折に触れて「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が有効なと
プロジェクトが進んで行くと、どんどんテストに時間が掛かるようになります。 let_it_be(Gem)も良さそうですが、その前に共通化で可読性を上げたり、 使われない処理が走らないようにRSpecを見直しました。 結論、subjectやlet（遅延実行）を上手く使うと可読性が上がる。 挙動やトランザクション範囲を把握しておくと速度を上げられる。 （1つ1つは小さいけど、数や回数の積み上げの影響が大きい） お作法や共通化の基本 RSpecは上から順番に処理するので、 定義した参照先（shared_contextやshared_examples_for）が 参照元（include_contextやit_behaves_like）よりも前にないとエラーになる。 ゆえに、テストケースや内容（条件や状態作成以外）は、下から上に書いて行く事になります。 describe: テスト対象（リクエスト先や目
FactoryBot（factory_bot_rails）にはinstanceを作るメソッドで buildと createが用意されている。 以前の職場で自動テストが重すぎて開発に支障が出ていた。 その時に話題に上がったのがテスト中にDBアクセスが多すぎることだった。 その時 createする必要がないものは buildにしましょうという事になったが、どういうことか全く理解してなかった。 なので、今回は build と createの違いを理解してみる。 build メモリ上にインスタンスを確保する。 DB上にはデータがないので、DBにアクセスする必要があるテストのときは使えない。 DBにアクセスする必要がないテストの時には、インスタンスを確保する時にDBにアクセスする必要がないので処理が比較的軽くなる。 create DB上にインスタンスを永続化する。 DB上にデータを作成する。 DBに
例えば、第一引数は何でもいいけど、第二引数で戻り値を振り分けたい場合などに使えます。 環境 RSpec: 3.8.0 例 cellの第二引数によって戻り値を変えたい場合。 before { allow(object).to receive(:cell).with(anything, 0).and_return("name") allow(object).to receive(:cell).with(anything, 1).and_return("type) } 参考 Matching arguments - Setting constraints - RSpec Mocks - RSpec - Relish
サイト終了のお知らせ
「iCARE Dev ブログ」は、2025年2月27日をもちまして終了いたしました。 長らくご覧いただきまして、誠にありがとうございました。 今後は iCARE Official Note をご覧いただければ幸いです。
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
RSpec3でbe_trueとbe_falseはなくなり、be_truthyとbe_falsey(be_falsy)になった - コード日進月歩
変化の経緯がなるほどなーと思ったのでまとめる。 出典 Notable Changes in RSpec 3 解説 RSpec3のリリースノートいわく RSpec 2 had a pair of matchers (be_true and be_false) that mirror Ruby's conditional semantics: be_true would pass for any value besides nil or false, and be_false would pass for nil or false. In RSpec 3, we've renamed these to be_truthy and be_falsey (or be_falsy, if you prefer that spelling) to make their semantics more e
関連: system specでNet::ReadTimeoutになったら - おもしろwebサービス開発日記チラシの裏 やっぱりタイムアウトの時間を伸ばすのではなく、テスト側でバリデーションの条件を緩和してあげたほうがトータルのテスト実行時間が短くなっていいんじゃないか、と思って次のようにした (設定はpalkan/anyway_config: Configuration library for Ruby gems and applicationsを使っています) class DailyReport < ApplicationRecord validates :body, presence: true, length: { maximum: -> { ValidationConfig.daily_report[:body][:maximum] } } end around do |exa
【Ruby on Rails】RSpecにおけるモックとスタブの基本事項メモ�【プログラミング学習開始142日目】 - Qiita
はじめに 個人用のメモです。 Railsチュートリアルを完走し、現在、Everyday Rails - RSpecによるRailsテスト入門を用いてRSpecの勉強を進めていたところ、10章にて「モックとスタブ」というものが出てきました。 初見ではあまり理解できなかったため、それぞれの定義や文法などの基本をさらうべくまとめてみました。 モックとスタブの定義・特徴・文法 モック テスト用の影武者として働くオブジェクト。 データベースへのアクセスなしで生成される（＝テストの時短に繋がる）。 doubleを用いて影武者を生成 スタブ テスト用のダミーメソッド。 データベースやネットワークを使うメソッドをデータベースへのアクセスなしで呼び出す。 allow(モデル名).to メソッドを用いてダミーメソッドを作成 使用例 以下の例ではuser = double("user", name: "Fake
結論 spec_helper.rbにrequireを書く。 具体例 require を書く場所 requireを書く場所はspec_helper.rbのどこでもいい*1のですが、私は一番下（endの直前）に書きます。以下のようになります。 RSpec.configure do |config| （省略） require "#{File.join(File.dirname(__FILE__), '../foo/bar')}" require "#{File.join(File.dirname(__FILE__), '../hoge/fuga')}" end File.dirname(__FILE__)はspec_helper.rbがある場所を指します。したがって上記の例ですとrequireするファイルは以下の二つになります。.rspecがある場所がルートディレクトリです。 foo/bar.r
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 自動テストを整備しておくと大量のテストを自動実行してくれるので大変便利です。 ですが、テストコードが増えてくると「パスするはずなのに、なぜかたまに失敗する」というテストが出てきます。 このような不安定なテストを「フレーキー（flaky）なテスト」と呼びます。 フレーキーなテストの問題点 フレーキーなテストは「たまに失敗するだけ」なので、何度かやり直せばパスします。 なので、GitHub ActionsのようなCIツール上でテストが落ちても、「あ、また落ちた。再実行したら直るかな（ポチッ）」という安易な解決策に走りがちです。 し
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[作成中]RSpecについて初学者段階のメモ - Qiita
【2024年4月】フリーランス案件の単価における市場動向【フリーランスボード】
rspec-openapiを導入した話 - Studyplus Engineering Blog
FactoryBot作成のベストプラクティス！？ - Blogメモφ(..)
【Rspec】ログイン機能をモジュールで共通化しテストコードをDRYにする - Qiita
RSpecでActiveRecordに依存しているConcernのspecを書く。 - Qiita
RSpecべからず集（DSLの構築が不適切な事例あれこれ） - Qiita
RSpecのexpectとis_expectedの挙動の違いについて - indilog
Rspecを使ってRailsでテストしてみた話 - 生存戦略型プログラミング
Rspecと Factoryの使い方 - Qiita
【RSpec】describe,context,itの使い分けについて - bokuの学習記録
CLI と Rubymine 上で RSpec を実行するための設定 | DriftwoodJP
RSpec Capybara href の無い a タグにハマる - かもメモ
rspec で起きた Lint/AmbiguousBlockAssociation の直し方
CapybaraなしでRailsアプリのE2Eテスト(feature spec)を実行する
rails specで特定のファイルを指定してテストする - Qiita
僕がRSpecでsubjectを使わない理由 - give IT a try
RSpecをリファクタリングして可読性と速度を上げる - Blogメモφ(..)
FactoryBotにおけるcreateとbuildの違い - Qiita
RSpec Mocksのwithをanythingで適用する - 料理とソフトウェアは似ている
Rspecでmoduleのテストを作成する - Qiita
E2Eテストでバリデーションを調整してタイムアウトを抑制する - おもしろwebサービス開発日記チラシの裏
単体で RSpec を使う際の require のやり方 - 約束の地
【RSpec】フレーキーなテスト（たまに落ちるテスト）の直し方 - Qiita