You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
はじめに 本記事では RSpec の request spec から OpenAPI 仕様のドキュメントを出力する Gem、rspec-openapi を紹介します。 ドキュメンテーションツール導入にあたっての負担を少なくしたい、実装とドキュメントが乖離しないようにしたい、という場合に参考になるかもしれません。 背景 これまで弊社では、 API ドキュメントは社内 wiki に蓄積されていました。 最初はこれでも問題にならなかったのですが、機能が増えてきたことによってドキュメントの数も増えて管理が難しくなったり、 フォーマットが明確でないので書く人によってばらつきがあるという問題がちらほら出てくるようになります。 API ドキュメント標準化といえば OpenAPI が思いつくものの、記述のために DSL を理解する必要があるとか追加で何か学習が必要となると、全員に浸透させるのはハードルが高
これはなに RSpecを利用したコントローラの機能テストは、Rails4まではcontroller specで行われて来ました。しかしRails5からはrequest specで記述することが推奨され、assignsとassert_templateの使用が非推奨となりました。 rails-controller-testinggemを使用すればassignsやassert_templateを使うことはできますが、やはりrequest specへ移行することが望ましいと考えられています。 これから新しく作成する Rails アプリケーションについては、 rails-controller-testing gem を追加するのはおすすめしません。 Rails チームや RSpec コアチームとしては、代わりに request spec を書くことを推奨します。 RSpec 3.5 がリリースされま
Sam Phippen, Myron Marston and Jon RoweJul 1, 2016RSpec 3.5 has just been released! Given our commitment to semantic versioning, this should be a trivial upgrade for anyone already using RSpec 3, but if we did introduce any regressions, please let us know, and we’ll get a patch release out with a fix ASAP. RSpec continues to be a community-driven project with contributors from all over the world.
リレーションの関係にある複数のモデルを連動して追加したいときの方法いろいろ. リレーション関係なくても、インスタンス生成と同時に特定の処理を実行したいときにも使える. 呼び出し側でcreateにブロック渡す rspecなどのテストコード側でカスタムに関連データを追加する方法. shop has_many staffsのリレーションができている前提で、以下のようにbuildやcreateにブロックを渡せば、ブロック内で生成されたインスタンスを自由に修正できる. # # 生成されたインスタンスの内容をブロック内で自由に修正できる # shop = FactoryBot.build(:shop) do |s| s.name = "あいうえお" end # # 永続化せずにインスタンス生成 # shopにひもづくstaffをブロック内で追加している # shop = FactoryBot.buil
はじめに FactoryBotでテストデータを作成するに当たってtraitを押さえるのは必須かなと思います。 RSpecをこれから始める方向けにこの記事を書きます。 traitを使ってみる 一例としてTaskのファクトリを作成する場面を想定してtraitを使ってみます。 # spec/factories/tasks.rb FactoryBot.define do factory :task do title { 'Task' } status { :todo } from = Date.parse("2019/08/01") to = Date.parse("2019/12/31") deadline { Random.rand(from..to) } trait :done do status { :done } completion_date { Time.current.yester
こんなエラー 隠れているので具体的にはこれ export WERCKER_STEP_ROOT="/pipeline/script-7824d588-c79c-427c-ab42-379f5d4c779f" export WERCKER_STEP_ID="script-7824d588-c79c-427c-ab42-379f5d4c779f" export WERCKER_STEP_OWNER="wercker" export WERCKER_STEP_NAME="script" export WERCKER_REPORT_NUMBERS_FILE="/report/script-7824d588-c79c-427c-ab42-379f5d4c779f/numbers.ini" export WERCKER_REPORT_MESSAGE_FILE="/report/script-7824d5
外部API呼び出しのあるアプリケーションを開発する場合、テストやローカル環境での動作確認まで本物のAPIを呼び出していると、時間がかかり開発の生産性が下がるのでAPIモックを使いたくなります。 そこでWebMockというGemを使うと、外部へのHTTPリクエストをスタブ化してくれるので、開発が非常にやりやすくなります。 今回はRailsアプリケーションでのWebMockの使い方を説明します。 インストール方法 Gemfileに書いてbundlerでインストールします。 gem 'webmock' bundle install --path vendor/bundle 設定方法 事前に自分の欲しいレスポンスを返却できるようにスタブを登録します。 (ここではレスポンスデータを事前に作成して、そのファイルを読み込むように指定しています) require 'webmock' WebMock.ena
— 環境 — rails-4.0.1 rspec-rails-2.14.0 capybara-2.2.0 RSpec メンテナの方に –profile オプションを教えてもらった それで、RSpec のテストが時間かかって遅い〜とつぶやいたところ、RSpec のメンテナの方からアドバイスを頂けました。Myron Marston さんありがとうございます!ブログでツイートと情報のシェアも承諾頂きました。 @takafumir The `–profile` option can be used to print out the slowest examples. — Myron Marston (@myronmarston) March 18, 2014 訳:– profile オプションを使うと遅いサンプルをリストアップできるよ。 ヘルプを見てみますと…
Capybara.javascript_driver = :poltergeist Capybara.register_driver :poltergeist do |app| Capybara::Poltergeist::Driver.new(app, :js_errors => false, :timeout => 60) end とすればよいとわかった。各オプションについて以下に説明する。 :js_errors :js_errors => falseにしたのはCapybara::Poltergeist::JavascriptError: というエラーを防ぐため。JSのエラーはよくあることなのだが、エラーが出るたびにCapybaraを止めるのは時間の無駄。ということで、JSのエラーは無視することにした。 :timeout Timeoutはデフォルトでは30秒。しかし、ログインのような時
というように書くようになりました。 別に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).
I'm trying to get Ruby debugger running in one of my specs: describe User do it "should be valid" do debugger User.new.should be_valid end end When I run rspec though, I get: debugger statement ignored, use -d or --debug option to enable debugging I've tried the following: rake spec --debug rake spec --debug --trace rake spec:models --debug bundle exec rspec --debug bundle exec rspec --debug spec/
describe User, 'something' do before :all do @user = User.make end it 'should so something' do # ... end it 'should so something else' do # ... end end 例えば上記の例の場合、@userは一度しか作られない。なのでそのレコードに対して一度変更を加えると、次のテストでもその変更が引き継がれ、独立したテストができなくなる。 加えて、before(:all)で作成されたデータは、テストが終わった後もロールバックされず、データベースに残ってしまう。なので、before(:all)でデータを作成した後は、after(:all)でデータベースをきれいにする必要がある。 before(:each)を使おう というわけで、データを作成する際にはbefore(
--profile オプションを使う 普段きちんとRSpecを使っている人にとっては常識なのかもしれません。というか普通にhelpに載っているので常識なのでしょう、、、。 RSpecで遅いテストを見つけるには、--profile オプションを使うと簡単に見つけることができます。 % bundle exec rspec --profile 3 .................................. Top 3 slowest examples (4.24 seconds, 61.5% of total time): Pooka Pooka::Master Worker#run worker received usr1 signal(signal_handler_thread Error) 1.41 seconds ./spec/pooka_spec.rb:86 Pooka Po
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く