14

JenkinsサードパーティのAPIがダウンしているか、互換性のないAPIをデプロイした場合にアラートを出すために、（を介して）自動化されたジョブを設定したいと思います。

私はHTTP APIsモックではなく実際のテストを行うことについて話していますが、すでにモックを使用して記述されてrspecいるため、2つの独立したテストを作成して作業を複製する必要があるかどうかはわかりません。

誰もがこれまでにこの経験をしたことがありますか？Ruby/Rspec（他のツールが役立つかどうかに限定されません）

4

4 に答える 4

5

ビデオデッキを見たことがありますか？これを使用すると、「テスト スイートの HTTP インタラクションを記録し、将来のテスト実行中にそれらを再生して、高速で決定論的で正確なテストを行うことができます」。外部 API からの予想される応答をテストするときに RSpec で使用しましたが、これは素晴らしいと思います。でタグ付けされた StackOverflow の質問を確認することをお勧めします。

Jenkins との統合についてはよくわかりませんが、VCR を使用していたときは、いつでもAPI を実行する必要がある通常のタスクをいくつか自動化しました(「Ruby での Cron ジョブ」)。実際には連続的ではありませんが、ある程度自動化されています。

于 2013-01-17T12:15:42.877 に答える
4

数か月前にこの状況に陥ったとき、私は次のことを行いました。

  1. API をモックし、モックされたデータに対してテストを作成します (既に持っています)。
  2. 実際の API からデータを取得し、それが (まだ) 同じ形式であり、期待するのと同じ種類のデータが含まれていることをアサートするテストをもう 1 つ作成します。

ライブ API によって提供されるコンテンツを推測/知ることは不可能だったので、このようにしました。

于 2013-01-17T13:30:41.153 に答える
3

モックは、実際のAPIに触れることなく独自のコードをテストするために使用されます。そして、実際のAPIをテストしたいとします。

したがって、たとえばサードパーティAPIの目立たないテストのために、RSpecで一連のテストを作成する必要があると思います。
「邪魔にならない」とは、たとえば、誤って「DELETE」APIリクエストを発行したり、1回のテストスイートの実行ですべての毎日のリクエストAPI制限を使用したりしないことを意味します。

指定されたAPIテストツールが存在するかどうかわからない。
私の場合、RSpecを使用して自分のリモートAPI/サーバーをテストして成功しました。

于 2013-01-17T09:54:39.907 に答える
2

既存のテスト スイートをライブで使用できるようにするために、2 つのことをdescribe行いitました。2 つ目は、の機能を使用しshared_contextsてブロックを取得します。

まず、実際の API に対して実行する仕様をメタデータでマークします。たとえば、これらが実際に実行できることを知りたいとします。

describe "Hitting the API with a call", :can_be_real do
  # …
end

これらの仕様は、tag オプションを使用してコマンドラインから実行できます。

2 つ目は、モックを本物に置き換えることです。それは、モックをどのように定義したか、 abeforeまたは aのどちらletが使用されたか、およびどれだけモックしたかによって異なります。ばかげた例として、以下を参照してください。

require 'rspec'

RSpec.configure do |c|
  c.treat_symbols_as_metadata_keys_with_true_values = true
end

shared_context "all my mocks and stubs" do
  let(:this) { false }
end

describe "a", :real do
  include_context "all my mocks and stubs" do
    let(:this) { true } if ENV["REAL_API_CALL"] == 'true'
    before do
      stub_const( "URI", Class.new ) unless ENV["REAL_API_CALL"] == 'true'
    end
  end
  it "should be real when it's real" do
    this.should == true
  end
  it "should escape things when it's real" do
    URI.should respond_to :escape
  end
end

bin/rspec example.rb出力を介してファイルを実行すると、次のようになります。

a
  should be real when it's real (FAILED - 1)
  should escape things when it's real (FAILED - 2)

Failures:

  1) a should be real when it's real
     Failure/Error: this.should == true
       expected: true
            got: false (using ==)
     # ./example.rb:19:in `block (2 levels) in <top (required)>'

  2) a should escape things when it's real
     Failure/Error: URI.should respond_to :escape
       expected URI to respond to :escape
     # ./example.rb:22:in `block (2 levels) in <top (required)>'

Finished in 0.00349 seconds
2 examples, 2 failures

経由で実行する場合env REAL_API_CALL=true bin/rspec example.rb:

a
  should be real when it's real
  should escape things when it's real

Finished in 0.00301 seconds
2 examples, 0 failures

ご覧のとおり、仕様のコンテキストをいくつかの方法で変更して、コマンド ライン (つまり Jenkins) から必要なレベルの制御を可能にすることができます。実際に実行しても安全かどうか、時間がかかるかどうかなど、他のメタデータで仕様をマークしたいと思うでしょう。

于 2013-01-23T07:09:15.683 に答える