RSpec driven API testing framework
I am looking for project maintainers to help keep airborne up to date and bug-free while avoiding feature creep and maintaining backwards compatibility.
Comment here if you would like to help out.
Install Airborne:
$ gem install airborneOr add it to your Gemfile:
gem 'airborne'require 'airborne'
describe 'sample spec' do
it 'should validate types' do
get 'http://example.com/api/v1/simple_get' #json api that returns { "name" : "John Doe" }
expect_json_types(name: :string)
end
it 'should validate values' do
get 'http://example.com/api/v1/simple_get' #json api that returns { "name" : "John Doe" }
expect_json(name: 'John Doe')
end
endWhen calling expect_json_types, these are the valid types that can be tested against:
:intor:integer:float:boolor:boolean:string:date:object:null:array:array_of_integersor:array_of_ints:array_of_floats:array_of_strings:array_of_booleansor:array_of_bools:array_of_objects:array_of_arrays
If the properties are optional and may not appear in the response, you can append _or_null to the types above.
describe 'sample spec' do
it 'should validate types' do
get 'http://example.com/api/v1/simple_get' #json api that returns { "name" : "John Doe" } or { "name" : "John Doe", "age" : 45 }
expect_json_types(name: :string, age: :int_or_null)
end
endAdditionally, if an entire object could be null, but you'd still want to test the types if it does exist, you can wrap the expectations in a call to optional:
it 'should allow optional nested hash' do
get '/simple_path_get' #may or may not return coordinates
expect_json_types('address.coordinates', optional(latitude: :float, longitude: :float))
endAdditionally, when calling expect_json, you can provide a regex pattern in a call to regex:
describe 'sample spec' do
it 'should validate types' do
get 'http://example.com/api/v1/simple_get' #json api that returns { "name" : "John Doe" }
expect_json(name: regex("^John"))
end
endWhen calling expect_json or expect_json_types, you can optionally provide a block and run your own rspec expectations:
describe 'sample spec' do
it 'should validate types' do
get 'http://example.com/api/v1/simple_get' #json api that returns { "name" : "John Doe" }
expect_json(name: -> (name){ expect(name.length).to eq(8) })
end
endCalling expect_json_sizes actually make use of the above feature and call expect_json under the hood:
describe 'sample spec' do
it 'should validate types' do
get 'http://example.com/api/v1/simple_get_collection' #json api that returns { "ids" : [1, 2, 3, 4] }
expect_json_sizes(ids: 4)
end
endAirborne uses rest_client to make the HTTP request, and supports all HTTP verbs. When creating a test, you can call any of the following methods: get, post, put, patch, delete, head, options. This will then give you access the following properties:
response- The HTTP response returned from the requestheaders- A symbolized hash of the response headers returned by the requestbody- The raw HTTP body returned from the requestjson_body- A symbolized hash representation of the JSON returned by the request
For example:
it 'should validate types' do
get 'http://example.com/api/v1/simple_get' #json api that returns { "name" : "John Doe" }
name = json_body[:name] #name will equal "John Doe"
body_as_string = body
endWhen calling any of the methods above, you can pass request headers to be used.
get 'http://example.com/api/v1/my_api', { 'x-auth-token' => 'my_token' }For requests that require a body (post, put, patch) you can pass the body as well:
post 'http://example.com/api/v1/my_api', { :name => 'John Doe' }, { 'x-auth-token' => 'my_token' }The body may be any JSON-serializable type, as long as you want to post application/json content type.
You may set a different content type and post a string body this way:
post 'http://example.com/api/v1/my_api', "Hello there!", { content_type: 'text/plain' }For requests that require Query params you can pass a params hash into headers.
post 'http://example.com/api/v1/my_api', { }, { 'params' => {'param_key' => 'param_value' } }SSL certificate verification is enabled by default (specifically, OpenSSL::SSL::VERIFY_PEER).
Carefully consider how you use this. It's not a solution for getting around a failed SSL cert verification; rather, it's intended for testing systems that don't have a legitimate SSL cert, such as a development or test environment.
You can override this behavior per request:
verify_ssl = false
post 'http://example.com/api/v1/my_api', "Hello there!", { content_type: 'text/plain' }, verify_sslor with a global Airborne configuration:
Airborne.configure do |config|
config.verify_ssl = false # equivalent to OpenSSL::SSL::VERIFY_NONE
endNote the per-request option always overrides the Airborne configuration:
before do
Airborne.configuration.verify_ssl = false
end
it 'will still verify the SSL certificate' do
verify_ssl = true
post 'http://example.com/api/v1/my_api', "Hello there!", { content_type: 'text/plain' }, verify_ssl
endYou can use the verify_ssl setting to override your global defaults in test blocks like this:
describe 'test something', verify_ssl: false do
endOR
describe 'test something' do
Airborne.configuration.verify_ssl = false
endThis feature currently isn't supported when testing loaded Rack applications (see "Testing Rack Applications" below). If you need to set verify_ssl: false, then we recommend starting your Rack app server and sending the airborne HTTP requests as you would when testing any other service.
If you have an existing Rack application like sinatra or grape you can run Airborne against your application and test without actually having a server running. To do that, just specify your rack application in your Airborne configuration:
Airborne.configure do |config|
config.rack_app = MySinatraApp
endUnder the covers, Airborne uses rack-test to make the requests.
If you're testing an API you've written in Rails, Airborne plays along with rspec-rails:
require 'rails_helper'
RSpec.describe HomeController, :type => :controller do
describe 'GET index' do
it 'returns correct types' do
get :index, :format => 'json' #if your route responds to both html and json
expect_json_types(foo: :string)
end
end
endexpect_json_types- Tests the types of the JSON property values returnedexpect_json- Tests the values of the JSON property values returnedexpect_json_keys- Tests the existence of the specified keys in the JSON objectexpect_json_sizes- Tests the sizes of the JSON property values returned, also test if the values are arraysexpect_status- Tests the HTTP status code returnedexpect_header- Tests for a specified header in the responseexpect_header_contains- Partial match test on a specified header
When calling expect_json_types, expect_json, expect_json_keys or expect_json_sizes you can optionally specify a path as a first parameter.
For example, if our API returns the following JSON:
{
"name": "Alex",
"address": {
"street": "Area 51",
"city": "Roswell",
"state": "NM",
"coordinates": {
"latitude": 33.3872,
"longitude": 104.5281
}
}
}This test would only test the address object:
describe 'path spec' do
it 'should allow simple path and verify only that path' do
get 'http://example.com/api/v1/simple_path_get'
expect_json_types('address', street: :string, city: :string, state: :string, coordinates: :object)
#or this
expect_json_types('address', street: :string, city: :string, state: :string, coordinates: { latitude: :float, longitude: :float })
end
endOr, to test the existence of specific keys:
it 'should allow nested paths' do
get 'http://example.com/api/v1/simple_path_get'
expect_json_keys('address', [:street, :city, :state, :coordinates])
endAlternatively, if we only want to test coordinates we can dot into just the coordinates:
it 'should allow nested paths' do
get 'http://example.com/api/v1/simple_path_get'
expect_json('address.coordinates', latitude: 33.3872, longitude: 104.5281)
endWhen dealing with arrays, we can optionally test all (*) or a single (? - any, 0 - index) element of the array:
Given the following JSON:
{
"cars": [
{
"make": "Tesla",
"model": "Model S"
},
{
"make": "Lamborghini",
"model": "Aventador"
}
]
}We can test against just the first car like this:
it 'should index into array and test against specific element' do
get '/array_api'
expect_json('cars.0', make: 'Tesla', model: 'Model S')
endTo test the types of all elements in the array:
it 'should test all elements of the array' do
get 'http://example.com/api/v1/array_api'
expect_json('cars.?', make: 'Tesla', model: 'Model S') # tests that one car in array matches the tesla
expect_json_types('cars.*', make: :string, model: :string) # tests all cars in array for make and model of type string
end* and ? work for nested arrays as well. Given the following JSON:
{
"cars": [
{
"make": "Tesla",
"model": "Model S",
"owners": [
{
"name": "Bart Simpson"
}
]
},
{
"make": "Lamborghini",
"model": "Aventador",
"owners": [
{
"name": "Peter Griffin"
}
]
}
]
}===
it 'should check all nested arrays for specified elements' do
get 'http://example.com/api/v1/array_with_nested'
expect_json_types('cars.*.owners.*', name: :string)
endJSON has no support for dates, however airborne gives you the ability to check for dates using the following. For expect_json_types you would use it as you would for any of the other types:
it 'should verify date type' do
get '/get_date' #api that returns {createdAt: "Mon Oct 20 2014 16:10:42 GMT-0400 (EDT)"}
expect_json_types(createdAt: :date)
endHowever if you want to check the actual date data with expect_json, you need to call the date function:
it 'should verify correct date value' do
get '/get_date' #api that returns {createdAt: "Mon Oct 20 2014 16:10:42 GMT-0400 (EDT)"}
prev_day = DateTime.new(2014,10,19)
next_day = DateTime.new(2014,10,21)
#within the date callback, you can use regular RSpec expectations that work with dates
expect_json(createdAt: date { |value| expect(value).to be_between(prev_day, next_day) })
endWhen setting up Airborne, you can call configure just like you would with rspec:
#config is the RSpec configuration and can be used just like it
Airborne.configure do |config|
config.include MyModule
endAdditionally, you can specify a base_url and default headers to be used on every request (unless overridden in the actual request):
Airborne.configure do |config|
config.base_url = 'http://example.com/api/v1'
config.headers = { 'x-auth-token' => 'my_token' }
end
describe 'spec' do
it 'now we no longer need the full url' do
get '/simple_get'
expect_json_types(name: :string)
end
endYou can also control the strictness of expect_json and expect_json_types with the global settings match_expected_default and match_actual_default like this.
Airborne.configure do |config|
config.match_expected_default = true
config.match_actual_default = false
endmatch_expected_default requires all the keys in the expected JSON are present in the response.
match_actual_default requires that the keys in the response are tested in the expected Hash.
So you can do the following combinations:
match_expected_default=false, match_actual_default=false - check only intersection
match_expected_default=false, match_actual_default=true - raise on extra key in response
match_expected_default=true, match_actual_default=false - raise on missing key in response
match_expected_default=true, match_actual_default=true - expect exact match
Airborne sets match_expected_default to true and match_actual_default to false by default.
You can use the match_expected and match_actual settings to override your global defaults in test blocks like this.
describe 'test something', match_expected: true, match_actual: false do
endOR
describe 'test something' do
Airborne.configuration.match_expected = true
Airborne.configuration.match_actual = false
end$ cd your/project
$ rspec spechttps://github.com/brooklynDev/airborne/graphs/contributors
Inspired by frisby.js
The MIT License
Copyright (c) 2014 brooklyndev, sethpollack
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent