24

REST API テスト用のキュウリ機能の手順を書き上げようとしています。

どちらのアプローチが優れているかわかりません：

Given I log in with username and password
When I add one "tv" into my cart
And I check my cart
Then I should see the item "tv" is in my cart

また

Given the client authenticate with username and password
When the client send POST to "/cart/add" with body "{item: body}"    
Then the response code should be "200"
And the response body should expect "{success: true}"
When the client send GET to "/cart"    
Then the response code should be "200"
And the response body should expect "{"items": ["tv"]}"

REST API のキュウリ手順を作成しようとするときに従うべき規則はありますか?

4

8 に答える 8

14

この役立つ記事に出くわしました: https://www.gregbeech.com/2014/01/19/effective-api-testing-with-cucumber/

要約する...

Scenario: List fruit
  Given the system knows about the following fruit:
    | name       | color  |
    | banana     | yellow |
    | strawberry | red    |
  When the client requests a list of fruit
  Then the response is a list containing 2 fruits
  And one fruit has the following attributes:
    | attribute | type   | value  |
    | name      | String | banana |
    | color     | String | yellow |
  And one fruit has the following attributes:
    | attribute | type   | value      |
    | name      | String | strawberry |
    | color     | String | red        |

JSON に対して結果を検証することは、結果が配列である場合、要素がテストで検証する方法と同じ順序ではない可能性があるため、扱いにくいビジネスです。

編集: finderAUT のコメントを使用してリンクを更新しました。ありがとう！

于 2014-05-09T17:08:39.453 に答える
7

これは、Pragmatic Programmer の「The Cucumber Book」が Cuke を介して REST API をテストすることについて述べている (十分に近い) 例であり、2 番目の例により密接に関連しているようです。

Feature: Addresses
  In order to complete the information on the place
  I need an address

Scenario: Addresses
  Given the system knows about the following addresses:
   [INSERT TABLE HERE or GRAB FROM DATABASE]
  When client requests GET /addresses
  Then the response should be JSON:
  """
    [
     {"venue": "foo", "address": "bar"},
     { more stuff }
    ]
  """
STEP DEFINITION:

Given(/^the system knows about the following addresses:$/) do |addresses| 
# table is a Cucumber::Ast::Table
  File.open('addresses.json', 'w') do |io|
    io.write(addresses.hashes.to_json)
  end
end    

When(/^client requests GET (.*)$/) do |path|
   @last_response = HTTParty.get('local host url goes here' + path)
end

Then /^the response should be JSON:$/ do |json|
   JSON.parse(@last_response.body).should == JSON.parse(json)
end
ENV File:

require File.join(File.dirname(__FILE__), '..', '..', 'address_app')
require 'rack/test'
require 'json'
require 'sinatra'
require 'cucumber'
require 'httparty'
require 'childprocess'
require 'timeout'

server = ChildProcess.build("rackup", "--port", "9000")
server.start
Timeout.timeout(3) do
  loop do
    begin
      HTTParty.get('local host here')
      break
    rescue Errno::ECONNREFUSED => try_again
      sleep 0.1
    end
  end
end

at_exit do
  server.stop
end
于 2013-06-05T19:20:47.970 に答える
6

私はキュウリを使用してテストを行い、さらに重要なことrails-apiに、現在のプロジェクトで使用して作成した API を文書化しています。使用するツールをいくつか探した結果、 cucumber-api-stepsとjson_specの組み合わせを使用することになりました。それは私にとってはうまくいきました。

きゅうりのステップの書き方に決まりはありません。手順を記述する方法は、cucumber スイートをどのように使用するかによって異なります。Angular JS クライアント開発者が API クライアントを実装するための参照として、キュウリの出力を使用しました。そのため、キュウリのステップには、実際の JSON 要求と応答、および各シナリオのステータス コードが含まれていました。これにより、何かが変更されたとき (特にクライアント側のチームが職場に物理的に存在していない場合) に、クライアント側のチームとのコミュニケーションが非常に簡単になりました。

API を作成または更新するたびに、CI サーバーはビルドの一部としてキュウリを実行し、HTML 形式の出力をブラウザーで開くことができる "build_artifacts" の場所に移動します。クライアント側の開発者は常に最新の参照を取得します。

テスト、文書化、およびバージョン管理された JSON API の作成に関するブログ投稿にこれらすべてを書き留めました。何らかの形で役立つことを願っています。

于 2013-08-02T09:09:23.810 に答える
5

その設計に貢献する Cucumber の当初の意図の 1 つは、技術的な実装とビジネス ニーズを知っている人々との間のギャップを埋めて、非開発者がテストの説明を記述および/または理解できるようにすることです。そのため、詳細な技術仕様や個別の単体テストにはあまり適していません。

したがって、それが Cucumber を使用している理由でもある場合は、最初のテストの説明を参照してください。

2 番目のバージョンのようなテストの実装に大きな問題はなく、Cucumber はそれをサポートできます。おそらく、解析する必要があるステートメントの種類もそれほど多くありません。しかし、テスト フレームワークと少し戦ったり、そもそも Cucumber を使用する根拠に反する結果になる可能性があります。

規約に関しては、実際にコメントできるほど十分な REST API テストがあることを私は認識していません。また、フレームワークとして Cucumber を使用したテストを見たものもありません。

更新:この件についてSOをブラウズすると、これへのリンクが見つかりました: https://github.com/jayzes/cucumber-api-stepsこれは、2番目の形式により似ています。

于 2013-05-24T18:57:44.897 に答える
0

最初の方がいいと思います。技術的なものは Ruby のクラスとモジュールに入れます。たとえば、when ステップのモジュールcart.add(items)のように、then ステップにexpect(cart.item).to include('items' => a_string_matching(item)) を配置します。

これにより、Ruby クラスとモジュールを別の機能ステップで再利用できます。たとえば、複数のアイテムをカートに追加して合計金額を検証する別のシナリオがあるとします。

ただし、2番目の1は、技術的な機能のようにすることができると思います. たとえば、すべての API で共通/グローバル ヘッダーまたはボディ リクエストが想定されます。

于 2016-01-11T03:19:21.923 に答える
0

ここを参照してください: https://github.com/ctco/cukes-rest . RESTful API をテストするための Cucumber DSL を提供します。

于 2016-07-12T09:37:40.230 に答える