About Weblog Tech Projects Sorry for the mess. I'm moving things around. It'll be better soon. In 2001 I started teaching Test-Driven Development to teams. Back then it was still a fairly new concept. Few teams had automated tests of any kind, and fewer still had heard of XP and TDD. Writing tests first and using the practise as a design activity was a completely foreign concept, and folks had a r
週刊Railsウォッチ（20201202後編）Rails 6.1 RC2リリース、Ruby STMの詳細な解説記事、RSpecのdiffを見やすくするsuper_diff gemほか｜TechRacho by BPS株式会社
2020.12.02 週刊Railsウォッチ（20201202後編）Rails 6.1 RC2リリース、Ruby STMの詳細な解説記事、RSpecのdiffを見やすくするsuper_diff gemほか こんにちは、hachi8833です。Rails 6.1 RC2が今朝リリースされたことをつい先ほど知りました。 各記事冒頭には⚓でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを（鍋のように）社内有志でつっついたときの会話の再構成です👄 お気づきの点がありましたら@hachi8833までメンションをいただければ確認・対応いたします🙇 ⚓ 臨時ニュース: Rails 6.1 RC2がリリース Rails 6.1 RC2 has been released! We are approaching the fi
こんにちは、アルダグラムの内倉です。 テスト書いていますか？ KANNA では現在、ci で多くの機能のテストをカバーしており、プロダクトの機能・要件が充実してきたこともあって、テスト数自体もかなり増えてきました。 結果、テストの実行時間が長く「ci 通ったらマージしますね」などといった際の待ち時間が負担となっていました。 テストデータの削除方法を見直したり、テストを並列実行にするなどの対策を行い、40〜60 分 → 10分弱まで短縮できていました。 しかし、今回さらに TestProf というテストのパフォーマンスを分析してくれる gem を使って、テスト自体の無駄をなくす方向で試してみたところ、以下のような条件では「ほんとに実行してるかな？」と疑うレベルで効果がありました。 テストで使用するデータの数が多い テストパターンが多い 今日は、今回の改善で行ったことを、ご紹介します👀 Te
RSpecのDefine negated matcherが地味に便利でした。 特にマッチャ合成式を書くときに便利です。 マッチャ合成式（Compound Matcher Expressions）とは andやorを使って、マッチャをつなげて書くことができます。 https://rspec.info/blog/2014/01/new-in-rspec-3-composable-matchers/ 例 適当ですが、Shopというモデルのインスタンスメソッド receive_order を実行した結果、CustomerモデルとOrderモデルのレコードが作成されることを確かめるテストがあるとします。 it 'customerとorderを作る' do expect { shop.receive_order }.to change(Customer, :count).by(1) expect {
Misoca のコードレビューで教えてもらった RSpec マッチャまとめ - mallowlabsの備忘録
この記事は Misoca+弥生 Advent Calendar 2019 の7日目の記事です。 はじめに Misoca に入社して1年とちょっとが経ちました。 Misoca は Ruby がメインの会社です。 私のキャリアはずっと Java だったので、特に RSpec の知識が貧弱で、RSpec は「expect って書くのは知ってる…」ぐらいの知識でした。 RSpec のマッチャは数も多く、いったいどこから勉強したらよいのか…というままテストコードを書いたため、コードレビューでよりよい書き方を教えてもらいつつやってきました。 そこで、同じ指摘をもらわないように自分用にまとめつつ、同じような境遇の人に少しでも役に立つように、Misoca のコードレビューで教えてもらった RSpec の書き方を紹介します。 注意事項として、以下で書き換え前と後のコードが出てきますが、どちらが良い悪いという
こんにちは。プロダクトエンジニアのkuritaです。普段はSmartHRの届出書類機能の開発をしています。2023年の2月に入社したのですが、いつのまにか半年が経っていました。半年って体感短いですね。 今回は、RSpecをリファクタリングした際の取り組みについてまとめました。 テストコードの読みづらさに課題を感じ、まさに今リファクタリングに取り組んでいる方の参考になれば幸いです。 RSpecを読んでいくなかで感じた課題 チームに入って少し時間が経ったころにアプリケーションの仕様がとても難しいことに気づきました。また、テストコードが読みづらいことで時間が掛かってしまい、仕様の把握も大変になっていました。そこで、仕様をキャッチアップするだけでなく、テストコードをより良い状態にすることも目的として、リファクタリングを進めることにしました。 Example groupが長すぎる 私たちが開発してい
Help us understand the problem. What are the problem?
前提 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/bb7d86dcd938c875f39fc34cc2c05b0c41c9056b/height=288;version=1;width=512/https%3A%2F%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-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCcnNwZWMlNUQlMjAlRTclODklQjklRTUlQUUlOUElRTMlODElQUUlRTMlODMlODYlRTMlODIlQjklRTMlODMlODglRTMlODElQUUlRTMlODElQkYlRTUlQUUlOUYlRTglQTElOEMlRTMlODElOTklRTMlODIlOEIlRTYlOTYlQjklRTYlQjMlOTUmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPWZkNDc2NjVlODU4OGQ3ZGZlNTBlMGE1NWVhYmQ3ZmUz%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB2aW5ha2EmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTNmNTUzYzQ2NGU1YTgxMDRiODFjN2I5NDUwNzE4NTJm%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Dfe95651da7cfc41edaa335bea09f3816)
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
morishitaです。 前回のエントリで、CodeBuild 上で RSpec を実行する環境について紹介しました。 tech.actindi.net その中で RSpec の結果を CodeBuild のレポートで確認できるようにしてみたらなかなか良かったのでそれについて紹介します。 CodeBuild のテストレポート機能とは １年ほど前に CodeBuild に追加された機能で、CodeBuild で実行したテスティングフレームワークの実行結果を管理し、見やすく表示する機能です。 例えば、複数回のテストの実行時間やエラー数をグラフにして表示できます。それを見れば、テストケースが増えてきたとか、実行時間がどれくらいとか傾向がわかります。 テスト結果トレンド また、１回のテスト実行結果を次のように表示できます。 1回のテスト結果 主に Java 系のテスティングフレームワークをサポート
【rails】rspecでcontrollerのconcern単体テストをやる方法 - ヤサゴリのプログラミングメモ帳
ことの始まり 巨大なcontrollerを分割した際、共通で使うメソッドはconcernにまとめておこうと考え。 controllerの単体テストでわざわざconcernの内容も一緒にやるのは馬鹿らしいので、concernの単体テストをやりたくなったが、ちょっと困ったので色々調べた。 せっかくなので、忘れないようにまとめておこう。 ベースとなるconcern 今回作ったのはこんな感じのconcern。 module HogeConcern extend ActiveSupport::Concern def fuga(order) # ハッシュを返し、nameキーに'maccho_'をつける end def piyo piyo_params = params.permit(~~) # permitの中は省略 # 頭に'maccho_'をつけたstrを返す end end fugaメソッドは引
まえがき こんにちは！SmartHR 基本機能の B チームで開発をしている@ron です。 今回は、私の所属する B チームで品質と開発効率の向上のため Jest を導入するにあたり、チームで行った議論と導入した結果をご紹介します。 Rails を使用している SmartHR では RSpec を使用してテストを実施していますが、テストが増えるにつれて CI での実行が非常に遅くなることが課題となっていました。 Jest を導入したことで、テストの網羅性が上がり、テストパターンを増やしつつ、テストの実行時間の増加を抑えることができました。 また、Jest を導入するにあたり、Jest と RSpec それぞれでどういったテストを書くべきか、どういったテストを書かないべきかを議論し、整理したので、その内容もお話しします。 SmartHR のプロダクト規模について SmartHR は、企業情
はじめに 皆様、こんにちは！ 佐久間まゆちゃんのプロデューサーの@hiroki_tanakaです。 私は現在、Railsを使用してメール送信機能を持つシステムを構築しているのですが、 Railsの持つActionMailer機能のRSpecでのテスト実装を少し調べたので紹介させて下さい。 記事の流れとしては、最初に利用環境とActionMailerを使うための下準備に触れ、 その後に実際のActionMailer側のコードとRSpecのコードを記載致します。 利用環境 Ruby 2.6.6 Rails 6.0.2 RSpec 3.9.1 下準備 今回はmailgunをESP（Email Service Provider)として、メール送信を行います。 そのため、mailgunで行った設定をdevelopment.rbに記載をして、rails側でmailgunを使用出来るように設定をします。
週刊Railsウォッチ: rubygemsに「scoped gems」の提案、RSpecのブロック構文ほか（20220517後編）｜TechRacho by BPS株式会社
週刊Railsウォッチについて 各記事冒頭には🔗でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを（鍋のように）社内有志でつっついたときの会話の再構成です👄 お気づきの点がありましたら@hachi8833までメンションをいただければ確認・対応いたします🙏 TechRachoではRubyやRailsなどの最新情報記事を平日に公開しています。TechRacho記事をいち早くお読みになりたい方はTwitterにて@techrachoのフォローをお願いします。また、タグやカテゴリごとにRSSフィードを購読することもできます（例:週刊Railsウォッチタグ） 🔗Ruby 🔗 scoped gemsの提案（Ruby Weeklyより） 元記事: Scoped gems proposal by mullermp ·
上のツイートを見て、どうやるのがいいか考えてみました。 以下がその方法です。 遅いテストに:slowタグを付けます（名前は:slowじゃなくても可）。
by David Elliott (Software Development Profession) We recently started a new Rails 5 project, and a conversation started around if we should be using RSpec controller or request specs. A quick google search shows that in the RSpec 3.5 release notes the recommendation is as follows: “For new Rails apps: we don’t recommend adding the rails-controller-testing gem to your application. The official rec
株式会社TECH LUCKという会社で代表兼エンジニアをしている齊藤です。 Rails on RailsのプロジェクトにGitHub ActionsでのCI/CDの導入を行う際の手順をまとめました。 本記事ではRspec, RubocopをGitHub Actionsで実行し、テストが落ちていることやコード規約に沿っていないことをGitHub上で検知できるようにします。 ※前提として、RspecやRubocopの実行に必要なGemや設定などは導入済みであるものとします。 github-action.ymlの作成 Railsプロジェクト内で.github/workflowsのディレクトを作成し、その中にgithub-action.ymlを作成します。 github-action.ymlの内容は以下のように記述します。 name: Run rspec, rubocop on: push: pu
Everyday Rails - RSpecによるRailsテスト入門がRails 7.1とRuby 3.3に対応しました！ - give IT a try
お知らせ 僕が翻訳している電子書籍「Everyday Rails - RSpecによるRailsテスト入門」をアップデートしました🎉 すでに本書を購入されている方はLeanpubのサイトから最新版の電子書籍ファイルを無料でダウンロードできます。 leanpub.com 2024年版のアップデート内容 今回のアップデート内容は以下の通りです。 サンプルアプリケーションをRails 7.1 + Ruby 3.3 + rspec-rails 6.1で再作成 これに伴い、サンプルアプリのリポジトリURLも変更 新しいサンプルアプリのコードや挙動にあわせて、本書の記述を修正 リンク切れしていたいくつかのリンクを新しいURLに修正 Rails 7.1で作った新しいサンプルアプリケーションは以下のGitHubリポジトリに置いています。 github.com とはいえ、書籍としてはほとんど内容は変わって
RSpecを書く上で意識した方がいいと思うことと少しのTips | Offers Tech Blog
こんにちは！Offersを開発しているバックエンドエンジニアのShunです。 前回「テストは絶対書いた方がいい」という記事を書いたので、今回はテストを書く上で留意していることを書ければと思います。 そもそも、テストは絶対書いた方がいい 単体テスト・結合テスト・UseCase テストを書いておくことで、テストファイルを見るだけで仕様を理解できたりします。 また、複雑なメソッドほどテストを書いておくことで、きちんと想定した出力を保証したメソッドの実装ができます。 さらに、一度書いたテストは追加機能・修正対応・リファクタリングなどを行った際に、影響してるか否かを自動でチェックしてくれます。 これにより、ユーザ様への円滑な価値提供並びにサービス品質を保証する大事な役割を担ってくれるのです。（テスト書いてなかった頃が恐ろしい） しかし、きちんと書けば書くほどテストのコード量が爆増する 書けば増えます
はじめに こんにちは。入社して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
はじめに：単純なバリデーションならテストコードは不要（という私見） Railsでモデルスペックを書くとき、バリデーションのテストを書く人をよく見かけます。 たとえば以下のようなイメージです。 RSpec.describe User, type: :model do # こういうテストは書く？書かない？？ describe 'validation' do example 'nameは必須' do user = User.new(name: '') expect(user).to be_invalid user.name = 'Alice' expect(user).to be_valid end end end 決して、バリデーションのテストを書くことが悪いことだとは言いませんが、個人的には単純なバリデーションであれば別に書かなくてもいいかな、と考えています。 単純なバリデーションにテストコ
RSpec でデータベースの「トランザクション分離レベル」の挙動を確認する｜TechRacho by BPS株式会社
ダーティリードとは、別トランザクションのコミットされていない変更データを読み込んでしまうこと ファジーリードとは、別トランザクションのコミットされた変更データを読み込んでしまうこと ファントムリードとは、別トランザクションで行追加（または削除）による変更データを読み込んでしまうこと やりたいこと 以下のシーケンス図のとおり、トランザクションAとトランザクションB（いずれも、データベーステーブルzandakas にアクセスするトランザクション）を動作させて、 トランザクションAで取得された結果zandakas_0 ～ zandakas_3 を「トランザクション分離レベル」ごとに確認する テーブル：zandakas(残高) カラム 型 トランザクション分離レベルの表をみてRSpec を書く # isolation_level_spec.rb require 'rails_helper' req
RSpecでは、before do ... endを使うことで、各テストケースの前に共通して行う処理を記述できる。これを使ってテストデータを投入する処理などを書いておくと、テストケースが書きやすくなる。 しかし、例えばデータが1件もない状態での挙動をテストしたいときなど、一部のケースではbeforeをスキップしたいという場合もある。そのための直接の機能はRSpecにはないが、以下のようにすると実現させることができる。 describe 'test_case' do before do |example| unless example.metadata[:skip_before] ... end end context 'condition A' do it 'needs before procedure' do # beforeが実行される ... end it 'not need bef
helperのテストの書き方を忘れるので、備忘録として投稿します。 以下のようにhelperに簡単なメソッドを用意して、テストを書いてみます。 helloというメソッドを実行すると、'hello'という文字列が返ってくる簡単なメソッドです。
TL;DR expect{subject}.to raise_error SystemExit exitをテストする状況はそもそも筋が悪い 前置き こんにちは。私は最近miというRails用のマイグレーションジェネレータを作っています。 github.com Railsのジェネレータは内部でThorというライブラリを使用しています。 このライブラリを使用していく上で、一つ問題が発生しました。 処理を途中で切り上げるためにexitメソッドを使用しないといけない事態に陥ってしまっていました。 問題点 exitはその時点でプロセスを終了するメソッドです。 このメソッドの問題点の一つに、テストがしづらくなると言うことがあります。 例えば、以下のようなメソッドをテストすることを考えます。 def do_something # ... if cond # ... exit 1 end # ... en
module Slack class Channel < ApplicationRecord ... end end
【🔴RSpecエラー】「Docker」+「Rails6」環境で、RSpecの結合テスト(SYSTEM）時にブラウザが起動しないについて
＜中略＞ group :development, :test do gem 'pry-rails' gem "rspec-rails", "~> 4.0.1" gem 'factory_bot_rails', '~> 5.0' end ＜中略＞ group :test do gem 'capybara', '~> 3.28' gem 'selenium-webdriver', '~> 3.142' # gem 'webdrivers', '~> 4.1' #「webdrivers」は、Docker上では使用しません。（以前は、chromedriver-helperという名称） end ＜中略＞ Selenium::WebDriver::Error::WebDriverError: Failure/Error: raise Error::WebDriverError, self.class.
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
RSpecにおけるparameterized testingとマネーフォワードにおけるその改善 - Money Forward Developers Blog
こんにちは。 Railsエンジニアのkamillleです。 マネーフォワードのアプリケーションはユーザーの権限やプラン・リクエスト時間等によって異なる振る舞いをするものが多く、そういった機能のテストではparameterized testingを利用することが多いです。マネーフォワードのRailsアプリケーションではテスティングフレームワークとしてRSpecが採用されることが多く、RSpecにおいてどのようにparameterized testingを行っているか紹介したいと思います。 RSpecにおけるparameterized testing RSpecはparameterized testingをサポートしていないので何かしらの拡張を行う必要があります。この拡張としてrspec-parameterizedというgemがあり、このgemが選ばれているケースが多いように思います。rspe
class Human def meet greeting = Greeting.new greeting.hello end end class Greeting def hello 'Hello!' end end 上記のコードに対して、Human#meet をテストしたいのですが、Greeting#hello は実際には呼び出したくなかったとします。 そのため、Greeting#hello をスタブする以下のようなテストコードを書いたとします。わかりやすいように、スタブした際の返り値を変更して、返り値が正しく変更されているかどうかを検証しています。 require_relative '../instance_stub' describe Human do context 'meet' do it 'returns a stub message instead of a real me
週刊Railsウォッチ: MinitestとRSpecの比較、商用版NGINXの重要機能がオープンソース化ほか（20220829前編）｜TechRacho by BPS株式会社
週刊Railsウォッチについて 各記事冒頭には🔗でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを（鍋のように）社内有志でつっついたときの会話の再構成です👄 お気づきの点がありましたら@hachi8833までメンションをいただければ確認・対応いたします🙏 TechRachoではRubyやRailsなどの最新情報記事を平日に公開しています。TechRacho記事をいち早くお読みになりたい方はTwitterにて@techrachoのフォローをお願いします。また、タグやカテゴリごとにRSSフィードを購読することもできます（例:週刊Railsウォッチタグ） 🔗Rails: 先週の改修（Rails公式ニュースより） 公式更新情報: Ruby on Rails — Bugfixes, improvements an
どうもはじめまして。 muryoimpl です。 前回のエントリ 食べチョクの自動テスト改善活動 〜これまでとこれから〜 で、自動テスト改善チームが発足したことを書きましたが、今回はその活動の中で実施した、RSpec による自動テストのカバレッジのデータ収集の自動化と、そのデータを利用した可視化について書きたいと思います。 これまではどう可視化していたか 食べチョクは Ruby on Rails で動いており、バックエンドの自動テストは RSpec を使って書いています。 テストカバレッジは定番の SimpleCov で計測して結果を HTML に出力し、テストケースごとの実行情報は RSpec JUnit Formatter を使って XML として出力して、GitHub Actions でそれらの情報を Code Climate に送信していました。 また、可視化という点では、以前ビビ
リーダブルRSpec（カスタムマッチャー+RSpec::ContextHelper編） - Qiita
読みやすいRSpec書いていますか？ 読みやすいRSpecって何？ 「簡潔でテストケースを見てテスト内容が理解しやすいもの」と考えています ここでのテストケースとは、it/exampleブロックのことを指しています 例題 例えば、Rails製REST APIのRequest Specを書くことを考えてみます コードは正しいか確認していないので、多少間違っていてもお許しください🙇 前提 APIはたくさんある 良くないけど、クエリパラメータのチェックをcontrollerでしているため、テストはRequest Specで行う APIの共通仕様 Server Errorを除き、HTTPステータスコードは必ず200で返す HTTPレスポンスボディはJSON形式で返す 成功時のレスポンス
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
はじめに 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実行の為
翻訳する目的 Everyday Rails - RSpecによるRailsテスト入門を読み、モック関連と、FactoryBotについて更に知識をつけたいと思いました。どちらも技術本で学ぶのは難しいので、リポジトリのREADMEを通じて学ぶのが良いと考えました。 Google翻訳やDeepLを用いて全文翻訳を行うと、日本語が不自然で読みにくかったので、今後何度も参照することを考えて、自分で翻訳することにしました。 FactoryBotのREADMEの翻訳は既に存在していたので、RSpec MocksのREADMEを翻訳することにしました。 翻訳時のルール Google翻訳やDeepLは利用しない。 わからない単語を辞書で調べるのはOK。 翻訳してみてどうだったか？ 良い点 英語のドキュメントを読む練習になる。 ドキュメントを細部までしっかり読む経験ができる。わからなくても投げ出さない経験がで
RSpecのオプションで遅いテストを探す
こんにちは。 GMOアドマーケティングのR.Sです。 今回は、RSpecでテストを遅い順に表示する--profileというオプションを紹介したいと思います。 profileとは 遅いテストをリストアップするオプションです。このオプションを使ってRSpecテストを実行すると下記のような形で出力されます。 Top 10 slowest examples (212.01 seconds, 25.7% of total time): test1 test1が正しく動くこと 42.83 seconds ./spec/~~~/test1_spec.rb:10 test2 test2が正しく動くこと 41.35 seconds ./spec/~~~/test2_spec.rb:29 test3 test3が正しく動くこと 27.16 seconds ./spec/~~~/test3_spec.rb:27
【2021年最新版】circleCI2.1 Ruby3.x + Rails6.x + MySQL8.x RSpec〜rubocop【M1Mac】 - Qiita
version: 2.1 orbs: ruby: circleci/ruby@1.1.3 node: circleci/node@4.5.1 jobs: build: docker: - image: cimg/ruby:3.0.1-node steps: - checkout - ruby/install-deps - node/install-packages: pkg-manager: yarn test: docker: - image: cimg/ruby:3.0.1-node environment: RAILS_ENV: test - image: circleci/mysql:latest command: mysqld --default-authentication-plugin=mysql_native_password environment: MYSQL_ALLO
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を使えばテスト対
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
History of RSpec - Steven R. Baker
RSpec の実行を高速におえるためのヒント
RSpecのDefine negated matcherが地味に便利 - Qiita
テストコードが読みづらかったのでRSpecをリファクタリングした話 - SmartHR Tech Blog
RSpecでNaNを判定する - Qiita
[rspec] 特定のテストのみ実行する方法 - Qiita
RSpec: Behaviour Driven Development for Ruby
CodeBuildのレポート機能を使ってRSpecの結果を見る - アクトインディ開発者ブログ
Jest を導入して RSpec と使い分け始めた話 - SmartHR Tech Blog
Rails6のActionMailer機能をRSpecでテストする方法 - Qiita
RSpecで遅いテストをふだんskipして、たまに全部実行する方法 - Qiita
RSpec — Controller or Request Specs?
RailsにGitHub Actionsの導入（Rspec, Rubocop）
RSpecで引数に特定の値が渡された時だけスタブしたい - ESM アジャイル事業部 開発者ブログ
【RSpec】Railsのモデルスペックでバリデーションのテストは書くべきか否か？ - Qiita
【Rails】RSpecで特定のテストケースだけbeforeをスキップする - りんごとバナナ
helperのRSpecの書き方 - Qiita
RSpecでexitを含むコードをテストする - pockestrap
【RSpec】名前空間のあるモデルのFactory生成 - Qiita
【RSpec】モックを使ったテスト | 働くひとと組織の健康を創る iCARE
RSpec でインスタンスメソッドがスタブできないときはインスタンスをモックする必要があるよという話
RSpec実行時のレポート情報をクエリで可視化する - 食べチョク開発者ブログ
Minitest vs. RSpec in Rails
RSpecの実行結果を分かりやすくするGitHub Actionを作った - Qiita
RSpec MocksのREADMEを翻訳 - Qiita