【Rails】GithubとCircleCIを連携してcommit時にrspecとrubocopを動かす - Qiita
rubocopに必須のセットアップは、特にないです。ただ、 .rubocop.yml は必須です。もし、迷うなら、 railsの .rubocop.yml をコピペ or 参考に作るといいです。 なお、自分のは以下の通りです。 AllCops: Exclude: - "tmp/**/*" - "config/initializers/*" - "vendor/**/*" - "db/schema.rb" - "node_modules/**/*" - "db/migrate/*.rb" - "bin/*" DisplayCopNames: true TargetRubyVersion: 2.6.0 Rails: Enabled: true Style/AndOr: EnforcedStyle: conditionals Style/AsciiComments: Enabled: false
RSpecで何をテストしたらいいのか決めてない時、とりあえずわたしが書いてるもの。 - Qiita
はじめに やりたいこと：カッコよくグリーンを出したい！ 「テストは大事！」とは言うものの、どんなRSpecを書いたらいいのかわからない...。 そんな状況が、Railsのお仕事に本格的に関わるようになってから、続いておりました。 そもそも自動テストには憧れがありますし、specを実行して、ターミナルに緑の文字を出したいのはやまやまです。でも、何を書けばいいのかわからない。 そんな時の、とりあえずの取りかかりの例を載せてみます。 ※ この記事の例について： 下記の例は、実際はテストとして無理に書く必要はないものだったりします。 自明なものを書きすぎると、たとえば全てのテストを通すのにも非常に時間がかかってしまいますので、このあたりは、rspecを動かす場合の確認用、1例として見ていただけると幸いです。 ※ これからRspecを始めたい方 / 初心者の方へ (20180523 追記) @jnc
実用的な新機能が盛りだくさん！RSpec 3.3 完全ガイド - Qiita
はじめに 2015年6月12日にRSpec 3.3がリリースされました。 APIが大きく変更されたり、派手な新機能が追加されたりはしていませんが、うまく活用するとテストを効率よく書いていけそうな実践的な新機能がたくさん導入されています。 この記事ではそんなRSpec 3.3の新機能を紹介していきます。 新機能一覧 RSpec 3.3で追加された主な新機能は以下の11個です。 これから各新機能の内容を紹介していきます。 特定のエクスペクテーション群をまとめて検証できる（aggregate_failures メソッド） グループやexampleをID指定して実行できる 失敗したテストだけを再実行できる（--only-failures オプション） 失敗したテストを1件ずつ修正できる（--next-failure オプション） テストが増減しても seed を指定したランダム実行が同じ順序で実行
RSpec - change の基本動作。 ( by / from / to の使い方 ) - Qiita
change 単に、状態が変わったことだけを検証する。 「何から何に変わったか」「どれぐらい変わったか」ということは気にしない。 x に 1 を足したら、change が成り立つ。
RSpec でキューイングした ActiveJob を同期実行する - Qiita
ジョブの実行をテストしたいとき、キューに入ったことをテストしたいだけのときと、その実行結果まで含めてテストしたいとき（つまり同期実行したいとき）がある。 前者であればRails.application.config.active_job.queue_adapter = :testで足りるが、後者を実現するためにはどうすればよいだろう。 方法はいくつかあって、まずはRails.application.config.active_job.queue_adapter = :inlineとする方法。 これは簡単に同期実行は実現できるが、こんどはキューに入ったことが確認できなくなってしまうし、他の非同期のままにしておきたいところまで影響がでてしまう。 またSidekiqを使っているのであればSidekiq::Testing.inline!やSidekiq::Testing.fake! で制御すること
Travis CIとRSpec + MySQLの連携 - Qiita
はじめに Travis CI上でMySQLを使う方法を調べたので自分用にメモ。公式サイトと以下のエントリを参考にさせていただきました。この記事ではRubyとRSpecを使っていますが、他の言語やテスティングフレームワークでもほぼ同じだと思います。 https://docs.travis-ci.com/user/database-setup/ http://qiita.com/suzuki86/items/e9682a242cad52003b08 設定手順 Travis CI上でユーザー名root(travisユーザーでも良いが権限がやや制限される)、パスワードなしでログインできる環境が自動的に立ち上がるため、こちら側で必要なのはテスト用データベース、テーブルの作成とdatabase.ymlの設定のみ .travis.ymlの設定 before_scriptに直接SQLを書いてもいいのですが
RSpecのフォーマッターの出力結果を任意のデータストアに保存できるgem rspec-storageを作った - Qiita
最近、手元でRSpecを全部流すなんてことはあんまり無くなってきた。 CIサービス上で結果は確認できても、色々情報を収集したり加工したりしたい場合ローカルのファイルシステムに吐くより、S3とかGCSとかに吐ける方が何かと便利なことが多い。 というわけで、gemで何とかしてみた。 https://github.com/joker1007/rspec-storage RSpec自体にこういう処理を差し込めるAPIが無いので、出来るだけメンテしやすい形でモンキーパッチを当てている。 こんな感じで使う。(GCSの場合はgs://) $ rspec -r rspec/storage spec/example_spec.rb -f doc -f json -o s3://your-bucket/spec_result.json パースして加工することを前提にするならjsonフォーマットで吐いておくのが
RSpecの(describe/context/example/it)の使い分け - Qiita
概要 なかなか使い分けする基準が理解できなかったけど、 こういうことかという考えが出てきたのでメモ。 使い分け方 テストの流れを端的に言うと、 機能、クラス、メソッドなどのテストの対象に対して、 特定の条件で実行してみて、 期待するアウトプットが返ってくるかを調べる、 ということになる。 ここで出てきたテストの対象と特定の条件とアウトプットに注目して、 (describe/context/example/it)の使い分けを行う。 describeには、テストの対象が何かを記述する。 contextには、特定の条件が何かを記述する。 exampleとitには、アウトプットが何かを記述する。日本語で記述するときはexampleを使う。it "is 〜やit { should be 〜 }のような形で書きたい場合はitを使う。 describe 'テストの対象' do context '特定の条
RSpecのletを使うのはどんなときか？（翻訳） - Qiita
はじめに RSpecにはletという機能があります。 これを使うとインスタンス変数を次のように置き換えることができます。 # インスタンス変数を使う場合 before do @user = User.new(name: 'Taro', email: 'taro@example.com') end it 'is valid' do expect(@user).to be_valid end # letを使う場合 let(:user) { User.new(name: 'Taro', email: 'taro@example.com') } it 'is valid' do expect(user).to be_valid end RSpecを使い慣れている人であれば、おそらくletを使うことが多いと思いますが、初心者の人には違いやメリットがよくわからないと思います。 また、使い慣れている人で
RSpecを並列実行するgemを作っている話 - Qiita
これは Ruby アドベントカレンダー 24 日目の記事です。 Railsを長く開発していると機能を追加していくにつれてテストコードも肥大化し、初めのうちは一瞬で終わっていたrspecも気がつけば数十分かかるようになっていたということも多いと思います。テストをCIで回していると、結果が得られるまで作業が止まることになるので、テスト時間の肥大化は結構大きなインパクトを持ってきます。 テストの中にボトルネックがある場合それを解消することである程度の高速化ができますが、純粋にテストの数が多いということになると、全てのテストを実行するのを諦めないのであれば、テストを並列に実行するのが高速化のアプローチとなります。 テストを並列実行するgem テストを並列に実行するgemはすでに世の中にいくつもあります。 rrrspec Cookpad社が作っているrrrspecはRSpecを複数サーバで分散実行し
rspecで共通するcontextやitをshared_examples_forでまとめる - Qiita
shared_examples_for 'test example' do |my_proc| context 'this is context' do it 'hoge' do expect(1).to eq 1 end it 'huga' do expect('1').to eq '1' end module_exec(&my_proc) end end describe 'foo' do include_examples 'test example', proc { it 'foo' do expect('foo').to eq 'foo' end } end describe 'bar' do include_examples 'test example', proc { it 'bar' do expect('bar').to eq 'bar' end } end
RSpec の入門とその一歩先へ、第2イテレーション ～RSpec 3バージョン～ - Qiita
はじめに 本記事は和田卓人さん(@t_wada)が書かれた有名なRSpec入門記事、「RSpec の入門とその一歩先へ、第2イテレーション」をRSpec 3バージョンとして書き直したものです。 詳しくは第1イテレーションに書いた説明を参照してください。 各イテレーション(RSpec 3バージョン)へのリンク 第1イテレーション 第2イテレーション(本記事) 第3イテレーション ソースコードのURL https://github.com/JunichiIto/rspec3-for-beginners/tree/end_of_iter2 本記事のライセンスについて 本記事は クリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 備考 本文やサンプルコードは極力オリジナルバージョンを踏襲します。 記述が古くなっている箇所は新しい記述方法に書き直します。 新しい記
Rspec の pending と skip って何が違うの？ - Qiita
何が違うか知らなかった時に調べたメモ。ちなみに Rspec 3 の話。 簡単に言うと以下のとおり。外的な要因で一時的に落ちているけど、いずれ通るようになる example は pending にすれば良いと思われる。（参考資料） pending: example が失敗したらテストは成功になる skip: example は実行されない pending は何らかの事情で example が失敗する原因を修正できない場合に使えば良い。パッチがマージされるまで example が失敗する場合など。そのような時に pending を使っておけば、example が失敗する原因が修正されたときに（pending な example が成功することで）テストが失敗するようになるので、もう pending にしておく必要がないと気づくことができる。あるいは原因不明だけど example が失敗している
RSpecのshouldはもう古い！新しい記法expectを使おう！
というように書くようになりました。 別にshouldを使った記法がなくなったわけではありませんが、 https://github.com/rspec/rspec-expectations のREADME.mdには、もう新しいSyntaxの説明しか載っていないし、今後はexpectの方を使っていくほうがいいでしょう。 http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax には、新しいSyntaxを導入した背景が説明されています。 簡潔に書くと、shouldだとBasicObjectを継承したクラスのテストを書くときに不具合が起こるみたいですね。 移行方法 基本 基本的には、上に書いたように、 foo.should を expect(foo).to に foo.should_not を expect(foo).
Grape + RSpec + json_expressions で Awesome な API の受け入れテスト - Qiita
Grape は Ruby で API を書くのに便利なフレームワークです。 Grape 自体については fakestarbaby 氏がすでにすてきなエントリを書いてくださっています。 Grape | API生成マイクロフレームワーク #Rails #Gems #Ruby #grape #api_builders - Qiita ここではどうやってテストを書くのかということについて書いてみたいと思います。 想定 RSpec の受け入れテストの request_spec を使うよ API は JSON を返すよ API 用のサブドメイン（api.foobar.com）を切っているよ JSON のテストは json_expressions を使うよ（参考） OAuth 2.0 の Provider になって Web Application Flow とかで認証しちゃったり モックは Factor
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
他人のRSpecを読むのはつらい - Qiita
RSpecにおけるFactoryGirlの使い方まとめ - Qiita
Rails RSpecの基本 ~Controller編~ - Qiita
wercker で Redis service を利用する - Qiita
Amazon Linux上のJenkinsでrbenv + Bundler + Rspecを動かす - Qiita
