REST API тэст агурка крокі лепшыя практыкі

Спроба пісаць крокі паўнаметражнага агурка для тэставання REST API.

Я не ўпэўнены, які падыход лепш:

Given I log in with username and passwабоd
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 passwабоd
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"]}"

Is there any convention to follow when people trying to write cucumber steps fабо REST API?

18

8 адказы

I just stumbled on this helpful article: http://gregbee.ch/blog/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 з'яўляецца складанай справай, таму што, калі вынік з'яўляецца масівам, элементы не могуць быць тым жа парадку, як вы праверка ў цесце.

12
дададзена
Вызначана згаджаюцца, што гэты метад лепш.
дададзена аўтар iamyojimbo, крыніца
Калі зацікаўленая асоба не з'яўляецца тэхнічнай, і вы не былі наняты, каб напісаць REST API у прыватнасці, вы не павінны быць «тэставанне» ваш API з агуркамі па-мойму. У адваротным выпадку, гэта лепшы адказ.
дададзена аўтар dan-klasson, крыніца
Калі зацікаўленая асоба не з'яўляецца тэхнічнай, і вы не былі наняты, каб напісаць REST API у прыватнасці, вы не павінны быць «тэставанне» ваш API з агуркамі па-мойму. У адваротным выпадку, гэта лепшы адказ.
дададзена аўтар dan-klasson, крыніца
Сумна тое аб гэтым метадзе: не так шмат паведамленняў пра гэта і не так шмат прыкладаў. Існуе праца.
дададзена аўтар Sebastian Schürmann, крыніца

Вось (досыць блізка) прыклад таго, што кажа: «Агуркі Кніга» прагматычны праграміст аб тэставанні REST API, з дапамогай агурочка, і, здаецца, больш цесна звязана з вашым другім прыкладам:

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
7
дададзена
Хоць я upvoting гэта для агульнай ідэі, я думаю, што патройны цытуемы JSON (або лал, ці аналагічны), як правіла, занадта нізкі ўзровень для крокаў агурка. Я б хутчэй выкарыстоўваць табліцу ключоў і значэнняў, хоць гэта, безумоўна, мае адваротны бок не апрацоўвае укладзеныя дадзеныя вельмі добра.
дададзена аўтар Marnen Laibow-Koser, крыніца
Вы цалкам маеце рацыю ... Я ў канчатковым выніку пераход да стала і выклік FactoryGirl.create для кожнага радка табліцы ... праверыць гэта: whitneytaylorimura.wordpress.com
дададзена аўтар Whitney Imura, крыніца

Я выкарыстоўваю агурок, каб праверыць і, што больш важна дакументаваць API, які я стварыў з дапамогай Рэйкі-Іза у маім бягучым праекце. Я агледзеўся для некаторых інструментаў для выкарыстання і я ў канчатковым выніку, выкарыстоўваючы камбінацыю агурка-ИПН крокаў і <�а HREF = "https://github.com/collectiveidea/json_spec"> json_spec . Ён працаваў добра для мяне.

Там няма канвенцыі аб тым, як пісаць крокі агурка. Тое, як вы пішаце свае крокі, залежыць ад таго, як вы хочаце выкарыстоўваць агурочны люкс. Я выкарыстаў выхад агурка ў якасці эталона для нашых кліентаў кутніх дэвов JS рэалізаваць кліент API. Так што мае крокі агурка ўтрымлівалі фактычныя запыты JSON і адказы разам з кодам стану для кожнага сцэнара. Гэта зрабіла яго вельмі лёгка мець зносіны з бакавой камандай кліента кожны раз, калі нешта зьмянілася (асабліва, калі на баку кліента каманда фізічна не прысутнічае на працоўным месцы).

Everytime Я хацеў бы стварыць або абнавіць API, сервер CI будзе працаваць агурок, як частка зборкі і перасоўванне HTML фарматаванага высновы ў «build_artifacts» месца, якое можна адкрыць у браўзэры. На баку кліента распрацоўшчыкі заўсёды атрымаюць апошняе значэнне такім чынам.

Я напісаў усё гэта ўніз ў блогу аб стварэнні правераны, задакументаваныя і версионируются JSON API , спадзяюся, гэта дапаможа вам у некаторым родзе.

6
дададзена

Адзін з арыгінальных намераў агурка, які ўносіць свае ўклад у яго канструкцыю, каб пераадолець разрыў паміж тэхнічнай рэалізацыяй, і людзьмі, якія ведаюць патрэбы бізнесу, так што апісання тэстаў могуць быць напісаны і/або разумець, якія не з'яўляюцца распрацоўшчыкамі. Такім чынам, гэта не выдатна падыходзіць для падрабязных тэхнічных спецыфікацый, або метадычнага модульнае тэставанне.

Так што б паказаць мне на ваша першае апісанне тэсту, калі гэта таксама прычына, вы карыстаецеся Агурок.

Там няма якіх-небудзь сур'ёзных праблем з рэалізацыяй тэстаў, як другі варыянт, агурка можа падтрымаць яго. Там, верагодна, не вялікая колькасць тыпаў аператараў вам трэба будзе разабраць небудзь. Але вы маглі б у канчатковым выніку барацьбу паверкавага Рамачнага трохі, або ісці супраць свайго абгрунтавання для выкарыстання Агурцоў ў першай чаргі.

Што тычыцца канвенцыі, я не ў курсе дастаткова тэстаў REST API на практыцы каментаваць, і ніхто, што я бачыў выпрабаванні выкарыстоўвалі Агуркі ў якасці асновы.

Абнаўленне: Прагляд вакол SO па гэтым пытанні, я знайшоў спасылку на гэты код: https://GitHub. кім/jayzes/агурок API-крокі , які больш падобны на свой другі фармат.

5
дададзена

Ёсць некалькі бібліятэк, цяпер на баку сервера REST тэставання з агурком ў <�моцны> лал . Вось некалькі:

Бібліятэка Я выкарыстоўваю для сервернай боку REST тэставання з агурком Агуркі-API-Steps </а >. Агуркі-API-Steps

<�Моцны> Вось як я б напісаць тэст, выкарыстоўваючы 'агурок-АПА-крокі' (рэкамендуецца):

@success
Scenario: Successfully add to cart
  Given I am logged in
  When I send a POST request to “/cart/add” with the following:
       | item | body |
  Then the response status should be “200”
  And the JSON response should have "success" with the text "true"
  When I send a GET request to “/cart”
  Then the response status should be “200”
  And the JSON response should be "{'items': ['tv']}"

<�Моцны> І вось што мае тэсты выглядаюць як з дапамогай 'агурок-АПА-крокі'

@success
Scenario: Successfully log in
  Given I am logged out
  When I send a POST request to “/login” with:
       | username | [email protected] |
       | password | mypassword |
  Then the response status should be “200”
  And the JSON response should have "firstName" with the text "Katie"

Агуркі-API

<�Моцны> Вось як я б напісаць тэст, выкарыстоўваючы 'агурка-АПА'

@success
Scenario: Successfully add to cart
  Given I am logged in
  When I send a POST request to “/cart/add”
       And I set JSON request body to '{item: body}'
  Then the response status should be “200”
  And the response should have key “success” with value “true”
  When I send a GET request to “/cart”
  Then the response status should be “200”
  And the response should follow "{'items': ['tv']}"

<�Моцны> І вось што мае тэсты выглядаюць як з дапамогай 'агурка-АПА'

@success
Scenario: Successfully log in
  Given I am logged out
  When I send a POST request to “/login” with:
       | username | [email protected] |
       | password | mypassword |
  Then the response status should be “200”
  And the response should have key “firstName”
  • Заўвага аб агурка-API: Там няма шляху ў цяперашні час, каб зрабіць павінен мець ключ «FirstName» са значэннем «Katie» . «Са значэннем» частка не была зроблена.
  • Таксама "Follow" чакае JSON-файл

Яшчэ адзін рэсурс тут , але яна старая (2011) ,

1
дададзена

Глядзіце тут: https://github.com/ctco/cukes-rest . Яна забяспечвае агурок DSL для тэставання RESTful API.

0
дададзена

I think the first one is better. I would put the technical in the ruby classes and modules. E.g like module cart.add(items) in the when step and in the then step put expect(cart.item).to include('items' => a_string_matching(item))

Да гэтага, класы лал і модулі могуць быць паўторна на іншы асаблівасці этапаў. Напрыклад, як, можа быць, у вас ёсць яшчэ адзін сцэнар, які б дадаць некалькі элементаў у кошык і пацвердзіце агульную суму.

Тым не менш, другой 1 я думаю, што можа гэта зрабіць, як тэхнічныя асаблівасці. Напрыклад, як агульны/глабальны загаловак або цела запыт, як чакаецца, па ўсёй АНІ.

0
дададзена

Я б парэкамендаваў свой першы сцэнар.

З майго ўласнага досведу я асабіста лічу, што самае вялікае значэнне, якое вы атрымліваеце ад выкарыстання BDD ў якасці спосабу дастаўкі праграмнага забеспячэння, калі вы змяшчаеце ўвагу на кошт бізнесу.

Іншымі словамі, сцэнары павінны быць прыклады таго, што паводзіны бізнэс хоча, а не тэхнічная рэалізацыя. Гэта гарантуе, што развіццё абумоўлена мэтамі бізнесу і чаканыя вынікі адпавядаюць іх чаканням.

Гэта вядома як звонку ў развіцці.

Дадатковыя тэсты паводзін сістэмы можа і <�моцнага> павінен выкарыстоўваюцца для пакрыцця тэхнічных патрабаванняў, але я думаю, што ёсць менш значэння выдаткаў высілкаў пісаць іх у натуральнай мове, які часцяком адымае шмат часу і працаёмкае ў вялікай колькасці сцэнарыяў.

Я рэкамендую наступны падыход:

1) Праца з БАВ і ДДУ распрацаваць прыклады паводзін, яны хочуць з дапамогай невнедрения канкрэтнага мовы (як ваш першы прыклад).

2) Інжынеры выкарыстоўваюць іх, каб стымуляваць развіццё з тэставага першага падыходу, аўтаматызацыі іх інтэграцыя тэстаў - з большасцю ніжэй браўзэра (супраць вашага REST API, напрыклад) і найбольш асноўных сцэнарыяў таксама праз браўзэр (калі вы распрацоўваеце адзін ).

3) Інжынеры TDD код функцыі з юніт-тэстаў, пакуль абодва модульныя тэсты і прыклады BDD не праходзяць.

0
дададзена