The following code tests image validation within a model spec in a Rails 4.2 app with RSpec 3.5 and the Shrine gem for file uploads.
My questions are:
Can you think of a way to improve the following tests or a better way to test those validations?
How to improve the speed of the file size validation test? If possible, I'd like to test it without actually having to upload a >10mb file.
Other aspects of the file upload setup are tested in controller and feature specs, which are irrelevant to this question.
RSpec.describe ShareImage, :type => :model do
describe "#image", :focus do
let(:image_file) do
# Could not get fixture_file_upload to work, but that's irrelevant
Rack::Test::UploadedFile.new(File.join(
ActionController::TestCase.fixture_path, 'files', filename))
end
let(:share_image) { FactoryGirl.build(:share_image, image: image_file) }
before(:each) { share_image.valid? }
context "with a valid image file" do
let(:filename) { 'image-valid.jpg' }
it "attaches the image to this record" do
expect(share_image.image.metadata["filename"]).to eq filename
end
end
context "with JPG extension and 'text/plain' media type" do
let(:filename) { 'image-with-text-media-type.jpg' }
it "is invalid" do
expect(share_image.errors[:image].to_s).to include("invalid file type")
end
end
# TODO: Refactor the following test (it takes ~50 seconds to run)
context "with a >10mb image file" do
let(:filename) { 'image-11mb.jpg' }
it "is invalid" do
expect(share_image.errors[:image].to_s).to include("too large")
end
end
end
end
I would recommend that you test metadata extraction and validation separately. The metadata extraction you need to test with real IOs, but for validation tests you can assign a cached file with the desired metadata which doesn't have to actually exist.
RSpec.describe ImageUploader do
def uploaded_file(metadata = {})
Shrine.uploaded_file(
"id" => "123",
"storage" => "cache",
"metadata" => {"mime_type" => "image/jpeg", "size" => 100}.merge(metadata)
)
end
let(:share_image) do
FactoryGirl.build(:share_image, image: uploaded_file(metadata).to_json)
end
let(:metadata) { Hash.new }
describe "validations" do
before(:each) { share_image.valid? }
context "when image is correct" do
it "passes" do
expect(share_image.errors).to be_empty
end
end
context "when extension is correct but MIME types isn't" do
let(:metadata) { Hash["filename" => "image.jpg", mime_type => "text/plain"] }
it "fails" do
expect(share_image.errors[:image].to_s).to include("isn't of allowed type")
end
end
context "when file is larger than 10MB" do
let(:metadata) { Hash["size" => 11 * 1024 * 1024] }
it "fails" do
expect(share_image.errors[:image].to_s).to include("too large")
end
end
end
end
Rather than routing uploads through Rack::Test::UploadedFile, create the attachment meta-data record directly using a fixture or factory or directly in the test. The end result should be that you have the attachment meta data (which is what is constructed when you upload a file) that references your file without having to run it through the upload code. I'm not sure about the specifics of doing this with Shrine, but this technique works well with libraries like Paperclip. In Shrine it looks like this will mean constructing a Shrine::UploadedFile record directly that references your file.
Related
I wanna test an action which attaches an image. I use a rSpec request spec.
The image gets attached in real requests, but the rspec fails Why?
def update_logo
if params[:logo].present?
image = params[:logo]
if image && #current_user.logo.attach(image)
puts #current_user.logo.attached? # !!! results in TRUE !!!
render json: #current_user, status: :ok
end
end
end
it "attaches a logo" do
post update_logo_url,
params: { logo: fixture_file_upload(file_fixture('400x400.png'), 'image/png') },
headers: { "Authorization" => token_generator(user.id) }
expect(user.logo).to be_attached
end
expected `#<ActiveStorage::Attached::One:0x00007fb9f57a90e8 #name="logo", #record=#<User id: 1, name: "....210787000 +0000">>.attached?` to be truthy, got false
BTW:
Other tests like ActiveStorage::Attachment.count works
So, this is "green":
it 'saves the uploaded file' do
expect {
subject
}.to change(ActiveStorage::Attachment, :count).by(1)
end
Try reloading the user instance before checking the attachment:
expect(user.reload.logo).to be_attached
# ----------^^^^^^
You're pulling the user out of the database before the request is made. Then the controller method will create its own instance, add the attachment, and save everything. But the user in your test won't know about any of that. If you user.reload, user will be refreshed with the latest information from the database and user.logo should be attached.
In my Rails tests I have this one failing randomly:
require 'spec_helper'
describe Api::V2::ClientsController, type: :controller do
context 'happy path' do
let!(:clients) {
[create(:client), create(:client)]
}
it 'return authorized user resource in JSON format' do
get :codes, format: :json
expect(response).to be_success
expect(json_response['clients'].size).to eql(2)
expect(json_response['clients'][0]).to eql('code' => clients[0].code)
expect(json_response['clients'][1]).to eql('code' => clients[1].code)
end
end
end
I'm not sure about using this:
let!(:clients) {
[create(:client), create(:client)]
}
I assume that your controller fetches the records in no specific order (e.g. Client.all) and that your database doesn't guarantee any default order, either.
In that case, you can use contains_exactly:
expect(json_response['clients'].size).to eql(2)
expect(json_response['clients']).to contain_exactly(
{ 'code' => clients[0].code },
{ 'code' => clients[1].code }
)
You could try swapping out the index numbers (json_response['clients'][0]) for something which doesn't rely on the json returned being in the right order.
For instance:
clients.each do |client|
expect(json_response['clients'].collect{|x|x['code']}).to include(client.code)
end
If this fixes the problem, you may want to order the client records being returned from your controller.
I'm using scaffolding to generate rspec controller tests. By default, it creates the test as:
let(:valid_attributes) {
skip("Add a hash of attributes valid for your model")
}
describe "PUT update" do
describe "with valid params" do
let(:new_attributes) {
skip("Add a hash of attributes valid for your model")
}
it "updates the requested doctor" do
company = Company.create! valid_attributes
put :update, {:id => company.to_param, :company => new_attributes}, valid_session
company.reload
skip("Add assertions for updated state")
end
Using FactoryGirl, I've filled this in with:
let(:valid_attributes) { FactoryGirl.build(:company).attributes.symbolize_keys }
describe "PUT update" do
describe "with valid params" do
let(:new_attributes) { FactoryGirl.build(:company, name: 'New Name').attributes.symbolize_keys }
it "updates the requested company", focus: true do
company = Company.create! valid_attributes
put :update, {:id => company.to_param, :company => new_attributes}, valid_session
company.reload
expect(assigns(:company).attributes.symbolize_keys[:name]).to eq(new_attributes[:name])
This works, but it seems like I should be able to test all attributes, instead of just testing the changed name. I tried changing the last line to:
class Hash
def delete_mutable_attributes
self.delete_if { |k, v| %w[id created_at updated_at].member?(k) }
end
end
expect(assigns(:company).attributes.delete_mutable_attributes.symbolize_keys).to eq(new_attributes)
That almost worked, but I'm getting the following error from rspec having to do with BigDecimal fields:
-:latitude => #<BigDecimal:7fe376b430c8,'0.8137713195 830835E2',27(27)>,
-:longitude => #<BigDecimal:7fe376b43078,'-0.1270954650 1027958E3',27(27)>,
+:latitude => #<BigDecimal:7fe3767eadb8,'0.8137713195 830835E2',27(27)>,
+:longitude => #<BigDecimal:7fe3767ead40,'-0.1270954650 1027958E3',27(27)>,
Using rspec, factory_girl, and scaffolding is incredibly common, so my questions are:
What is a good example of an rspec and factory_girl test for a PUT update with valid params?
Is it necessary to use attributes.symbolize_keys and to delete the mutable keys? How can I get those BigDecimal objects to evaluate as eq?
Ok so this is how I do, I don't pretend to strictly follow the best practices, but I focus on precision of my tests, clarity of my code, and fast execution of my suite.
So let take example of a UserController
1- I do not use FactoryGirl to define the attributes to post to my controller, because I want to keep control of those attributes. FactoryGirl is useful to create record, but you always should set manually the data involved in the operation you are testing, it's better for readability and consistency.
In this regard we will manually define the posted attributes
let(:valid_update_attributes) { {first_name: 'updated_first_name', last_name: 'updated_last_name'} }
2- Then I define the attributes I expect for the updated record, it can be an exact copy of the posted attributes, but it can be that the controller do some extra work and we also want to test that. So let's say for our example that once our user updated his personal information our controller automatically add a need_admin_validation flag
let(:expected_update_attributes) { valid_update_attributes.merge(need_admin_validation: true) }
That's also where you can add assertion for attribute that must remain unchanged. Example with the field age, but it can be anything
let(:expected_update_attributes) { valid_update_attributes.merge(age: 25, need_admin_validation: true) }
3- I define the action, in a let block. Together with the previous 2 let I find it makes my specs very readable. And it also make easy to write shared_examples
let(:action) { patch :update, format: :js, id: record.id, user: valid_update_attributes }
4- (from that point everything is in shared example and custom rspec matchers in my projects) Time to create the original record, for that we can use FactoryGirl
let!(:record) { FactoryGirl.create :user, :with_our_custom_traits, age: 25 }
As you can see we manually set the value for age as we want to verify it did not change during the update action. Also, even if the factory already set the age to 25 I always overwrite it so my test won't break if I change the factory.
Second thing to note: here we use let! with a bang. That is because sometimes you may want to test your controller's fail action, and the best way to do that is to stub valid? and return false. Once you stub valid? you can't create records for the same class anymore, therefor let! with a bang would create the record before the stub of valid?
5- The assertions itself (and finally the answer to your question)
before { action }
it {
assert_record_values record.reload, expected_update_attributes
is_expected.to redirect_to(record)
expect(controller.notice).to eq('User was successfully updated.')
}
Summarize So adding all the above, this is how the spec looks like
describe 'PATCH update' do
let(:valid_update_attributes) { {first_name: 'updated_first_name', last_name: 'updated_last_name'} }
let(:expected_update_attributes) { valid_update_attributes.merge(age: 25, need_admin_validation: true) }
let(:action) { patch :update, format: :js, id: record.id, user: valid_update_attributes }
let(:record) { FactoryGirl.create :user, :with_our_custom_traits, age: 25 }
before { action }
it {
assert_record_values record.reload, expected_update_attributes
is_expected.to redirect_to(record)
expect(controller.notice).to eq('User was successfully updated.')
}
end
assert_record_values is the helper that will make your rspec simpler.
def assert_record_values(record, values)
values.each do |field, value|
record_value = record.send field
record_value = record_value.to_s if (record_value.is_a? BigDecimal and value.is_a? String) or (record_value.is_a? Date and value.is_a? String)
expect(record_value).to eq(value)
end
end
As you can see with this simple helper when we expect for a BigDecimal, we can just write the following, and the helper do the rest
let(:expected_update_attributes) { {latitude: '0.8137713195'} }
So at the end, and to conclude, when you have written your shared_examples, helpers, and custom matchers, you can keep your specs super DRY. As soon as you start repeating the same thing in your controllers specs find how you can refactor this. It may take time at first, but when its done you can write the tests for a whole controller in few minutes
And a last word (I can't stop, I love Rspec) here is how my full helper look like. It is usable for anything in fact, not just models.
def assert_records_values(records, values)
expect(records.length).to eq(values.count), "Expected <#{values.count}> number of records, got <#{records.count}>\n\nRecords:\n#{records.to_a}"
records.each_with_index do |record, index|
assert_record_values record, values[index], index: index
end
end
def assert_record_values(record, values, index: nil)
values.each do |field, value|
record_value = [field].flatten.inject(record) { |object, method| object.try :send, method }
record_value = record_value.to_s if (record_value.is_a? BigDecimal and value.is_a? String) or (record_value.is_a? Date and value.is_a? String)
expect_string_or_regexp record_value, value,
"#{"(index #{index}) " if index}<#{field}> value expected to be <#{value.inspect}>. Got <#{record_value.inspect}>"
end
end
def expect_string_or_regexp(value, expected, message = nil)
if expected.is_a? String
expect(value).to eq(expected), message
else
expect(value).to match(expected), message
end
end
This is the questioner posting. I had to go down the rabbit hole a bit in understanding multiple, overlapping issues here, so I just wanted to report back on the solution I found.
tldr; It's too much trouble trying to confirm that every important attribute comes back unchanged from a PUT. Just check that the changed attribute is what you expect.
The issues I encountered:
FactoryGirl.attributes_for does not return all values, so FactoryGirl: attributes_for not giving me associated attributes suggests using (Factory.build :company).attributes.symbolize_keys, which winds up creating new problems.
Specifically, Rails 4.1 enums show as integers instead of enum values, as reported here: https://github.com/thoughtbot/factory_girl/issues/680
It turns out that the BigDecimal issue was a red herring, caused by a bug in the rspec matcher which produces incorrect diffs. This was established here: https://github.com/rspec/rspec-core/issues/1649
The actual matcher failure is caused by Date values that don't match. This is due to the time returned being different, but it doesn't show because Date.inspect does not show milliseconds.
I got around these problems with a monkey patched Hash method that symbolizes keys and stringifes values.
Here's the Hash method, which could go in rails_spec.rb:
class Hash
def symbolize_and_stringify
Hash[
self
.delete_if { |k, v| %w[id created_at updated_at].member?(k) }
.map { |k, v| [k.to_sym, v.to_s] }
]
end
end
Alternatively (and perhaps preferably) I could have written a custom rspec matcher than iterates through each attribute and compares their values individually, which would have worked around the date issue. That was the approach of the assert_records_values method at the bottom of the answer I selected by #Benjamin_Sinclaire (for which, thank you).
However, I decided instead to go back to the much, much simpler approach of sticking with attributes_for and just comparing the attribute I changed. Specifically:
let(:valid_attributes) { FactoryGirl.attributes_for(:company) }
let(:valid_session) { {} }
describe "PUT update" do
describe "with valid params" do
let(:new_attributes) { FactoryGirl.attributes_for(:company, name: 'New Name') }
it "updates the requested company" do
company = Company.create! valid_attributes
put :update, {:id => company.to_param, :company => new_attributes}, valid_session
company.reload
expect(assigns(:company).attributes['name']).to match(new_attributes[:name])
end
I hope this post allows others to avoid repeating my investigations.
Well, I did something that's quite simpler, I'm using Fabricator, but I'm pretty sure it's the same with FactoryGirl:
let(:new_attributes) ( { "phone" => 87276251 } )
it "updates the requested patient" do
patient = Fabricate :patient
put :update, id: patient.to_param, patient: new_attributes
patient.reload
# skip("Add assertions for updated state")
expect(patient.attributes).to include( { "phone" => 87276251 } )
end
Also, I'm not sure why you are building a new factory, PUT verb is supposed to add new stuff, right?. And what you are testing if what you added in the first place (new_attributes), happens to exist after the put in the same model.
This code can be used to solve your two issues:
it "updates the requested patient" do
patient = Patient.create! valid_attributes
patient_before = JSON.parse(patient.to_json).symbolize_keys
put :update, { :id => patient.to_param, :patient => new_attributes }, valid_session
patient.reload
patient_after = JSON.parse(patient.to_json).symbolize_keys
patient_after.delete(:updated_at)
patient_after.keys.each do |attribute_name|
if new_attributes.keys.include? attribute_name
# expect updated attributes to have changed:
expect(patient_after[attribute_name]).to eq new_attributes[attribute_name].to_s
else
# expect non-updated attributes to not have changed:
expect(patient_after[attribute_name]).to eq patient_before[attribute_name]
end
end
end
It solves the problem of comparing floating point numbers by converting the values to it string representation using JSON.
It also solves the problem of checking that the new values have been updated but the rest of the attributes have not changed.
In my experience, though, as the complexity grows, the usual thing to do is to check some specific object state instead of "expecting that the attributes I don't update won't change". Imagine, for instance, having some other attributes changing as the update is done in the controller, like "remaining items", "some status attributes"... You would like to check the specific expected changes, that may be more than the updated attributes.
Here is my way of testing PUT. That is a snippet from my notes_controller_spec, the main idea should be clear (tell me if not):
RSpec.describe NotesController, :type => :controller do
let(:note) { FactoryGirl.create(:note) }
let(:valid_note_params) { FactoryGirl.attributes_for(:note) }
let(:request_params) { {} }
...
describe "PUT 'update'" do
subject { put 'update', request_params }
before(:each) { request_params[:id] = note.id }
context 'with valid note params' do
before(:each) { request_params[:note] = valid_note_params }
it 'updates the note in database' do
expect{ subject }.to change{ Note.where(valid_note_params).count }.by(1)
end
end
end
end
Instead of FactoryGirl.build(:company).attributes.symbolize_keys, I'd write FactoryGirl.attributes_for(:company). It is shorter and contains only parameters that you specified in your factory.
Unfortunately that is all I can say about your questions.
P.S. Though if you lay BigDecimal equality check on database layer by writing in style like
expect{ subject }.to change{ Note.where(valid_note_params).count }.by(1)
this may work for you.
Testing the rails application with rspec-rails gem.
Created the scaffold of user.
Now you need to pass all the examples for the user_controller_spec.rb
This has already written by the scaffold generator. Just implement
let(:valid_attributes){ hash_of_your_attributes} .. like below
let(:valid_attributes) {{ first_name: "Virender", last_name: "Sehwag", gender: "Male"}
}
Now will pass many examples from this file.
For invalid_attributes be sure to add the validations on any of field and
let(:invalid_attributes) {{first_name: "br"}
}
In the users model .. validation for first_name is as =>
validates :first_name, length: {minimum: 5}, allow_blank: true
Now all the examples created by the generators will pass for this controller_spec
I've external API endpoint, let's say: http://www.fake_me_hard.com/api. I would like to make some calls to this from my app.
Endpoint accepts following structure as argument:
{
:amount => amount,
:backurl => root_path,
:language => locale,
:orderid => order_id,
:pm => payment_method,
:accept_url => "/payment/success",
:exception_url => "/payment/failure",
}
For collecting this hash is responsible method EndpointRequestCollector.give_me_hash.
How I should test if give_me_hash returns proper structure ?
I can use the same strategy for creating this structure in specs and class as well so:
class EndpointRequestsCollector
def self.give_me_hash
{
#....collecting hash #1
}
end
end
describe EndpointRequestCollector do
context '.give_me_hash' do
it 'returns proper structure' do
expect(described_class.give_me_hash).to eq(
{
#... collecting hash #2
}
)
end
end
end
...but it would be repeating the same code in 2 places, and won't test anything.
Do you know any good approach to this problem ?
This is the way that i usually test my json api's:
If you just want to test the format, you can use include matcher:
%w(my awesome keys).each do |expected_key|
expect(described_class.give_me_hash.keys).to include(expected_key)
end
By doing this, you have the guarantee that the formar is correct, until someone break you method.
If you want to test the returned values, you can use something like that:
let(:correct_value) { 42 }
it 'must have correct value' do
expect(described_class.give_me_hash[key]). to eq correct_value
end
But i recomment you to separate this the logic to get the value to another method, and make another test just for it.
Perhaps:
let(:args) {["amount", "backurl", "language", "orderid", "pm", "accept_url", "exception_url"]}
#...
it 'returns proper structure' do
described_class.give_me_hash.each_key do |key|
expect(key).to satisfy{|key| args.include?(key)}
end
end
I have the following code in my controller:
format.json { render :json => {
:flashcard => #flashcard,
:lesson => #lesson,
:success => true
}
In my RSpec controller test I want to verify that a certain scenario does receive a success json response so I had the following line:
controller.should_receive(:render).with(hash_including(:success => true))
Although when I run my tests I get the following error:
Failure/Error: controller.should_receive(:render).with(hash_including(:success => false))
(#<AnnoController:0x00000002de0560>).render(hash_including(:success=>false))
expected: 1 time
received: 0 times
Am I checking the response incorrectly?
You could parse the response body like this:
parsed_body = JSON.parse(response.body)
Then you can make your assertions against that parsed content.
parsed_body["foo"].should == "bar"
You can examine the response object and verify that it contains the expected value:
#expected = {
:flashcard => #flashcard,
:lesson => #lesson,
:success => true
}.to_json
get :action # replace with action name / params as necessary
response.body.should == #expected
EDIT
Changing this to a post makes it a bit trickier. Here's a way to handle it:
it "responds with JSON" do
my_model = stub_model(MyModel,:save=>true)
MyModel.stub(:new).with({'these' => 'params'}) { my_model }
post :create, :my_model => {'these' => 'params'}, :format => :json
response.body.should == my_model.to_json
end
Note that mock_model will not respond to to_json, so either stub_model or a real model instance is needed.
Building off of Kevin Trowbridge's answer
response.header['Content-Type'].should include 'application/json'
There's also the json_spec gem, which is worth a look
https://github.com/collectiveidea/json_spec
Simple and easy to way to do this.
# set some variable on success like :success => true in your controller
controller.rb
render :json => {:success => true, :data => data} # on success
spec_controller.rb
parse_json = JSON(response.body)
parse_json["success"].should == true
You can also define a helper function inside spec/support/
module ApiHelpers
def json_body
JSON.parse(response.body)
end
end
RSpec.configure do |config|
config.include ApiHelpers, type: :request
end
and use json_body whenever you need to access the JSON response.
For example, inside your request spec you can use it directly
context 'when the request contains an authentication header' do
it 'should return the user info' do
user = create(:user)
get URL, headers: authenticated_header(user)
expect(response).to have_http_status(:ok)
expect(response.content_type).to eq('application/vnd.api+json')
expect(json_body["data"]["attributes"]["email"]).to eq(user.email)
expect(json_body["data"]["attributes"]["name"]).to eq(user.name)
end
end
Another approach to test just for a JSON response (not that the content within contains an expected value), is to parse the response using ActiveSupport:
ActiveSupport::JSON.decode(response.body).should_not be_nil
If the response is not parsable JSON an exception will be thrown and the test will fail.
You could look into the 'Content-Type' header to see that it is correct?
response.header['Content-Type'].should include 'text/javascript'
When using Rails 5 (currently still in beta), there's a new method, parsed_body on the test response, which will return the response parsed as what the last request was encoded at.
The commit on GitHub: https://github.com/rails/rails/commit/eee3534b
A lot of the above answers are a bit out of date, so this is a quick summary for a more recent version of RSpec (3.8+). This solution raises no warnings from rubocop-rspec and is inline with rspec best practices:
A successful JSON response is identified by two things:
The content type of the response is application/json
The body of the response can be parsed without errors
Assuming that the response object is the anonymous subject of the test, both of the above conditions can be validate using Rspec's built in matchers:
context 'when response is received' do
subject { response }
# check for a successful JSON response
it { is_expected.to have_attributes(content_type: include('application/json')) }
it { is_expected.to have_attributes(body: satisfy { |v| JSON.parse(v) }) }
# validates OP's condition
it { is_expected.to satisfy { |v| JSON.parse(v.body).key?('success') }
it { is_expected.to satisfy { |v| JSON.parse(v.body)['success'] == true }
end
If you're prepared to name your subject then the above tests can be simplified further:
context 'when response is received' do
subject(:response) { response }
it 'responds with a valid content type' do
expect(response.content_type).to include('application/json')
end
it 'responds with a valid json object' do
expect { JSON.parse(response.body) }.not_to raise_error
end
it 'validates OPs condition' do
expect(JSON.parse(response.body, symoblize_names: true))
.to include(success: true)
end
end
JSON comparison solution
Yields a clean but potentially large Diff:
actual = JSON.parse(response.body, symbolize_names: true)
expected = { foo: "bar" }
expect(actual).to eq expected
Example of console output from real data:
expected: {:story=>{:id=>1, :name=>"The Shire"}}
got: {:story=>{:id=>1, :name=>"The Shire", :description=>nil, :body=>nil, :number=>1}}
(compared using ==)
Diff:
## -1,2 +1,2 ##
-:story => {:id=>1, :name=>"The Shire"},
+:story => {:id=>1, :name=>"The Shire", :description=>nil, ...}
(Thanks to comment by #floatingrock)
String comparison solution
If you want an iron-clad solution, you should avoid using parsers which could introduce false positive equality; compare the response body against a string. e.g:
actual = response.body
expected = ({ foo: "bar" }).to_json
expect(actual).to eq expected
But this second solution is less visually friendly as it uses serialized JSON which would include lots of escaped quotation marks.
Custom matcher solution
I tend to write myself a custom matcher that does a much better job of pinpointing at exactly which recursive slot the JSON paths differ. Add the following to your rspec macros:
def expect_response(actual, expected_status, expected_body = nil)
expect(response).to have_http_status(expected_status)
if expected_body
body = JSON.parse(actual.body, symbolize_names: true)
expect_json_eq(body, expected_body)
end
end
def expect_json_eq(actual, expected, path = "")
expect(actual.class).to eq(expected.class), "Type mismatch at path: #{path}"
if expected.class == Hash
expect(actual.keys).to match_array(expected.keys), "Keys mismatch at path: #{path}"
expected.keys.each do |key|
expect_json_eq(actual[key], expected[key], "#{path}/:#{key}")
end
elsif expected.class == Array
expected.each_with_index do |e, index|
expect_json_eq(actual[index], expected[index], "#{path}[#{index}]")
end
else
expect(actual).to eq(expected), "Type #{expected.class} expected #{expected.inspect} but got #{actual.inspect} at path: #{path}"
end
end
Example of usage 1:
expect_response(response, :no_content)
Example of usage 2:
expect_response(response, :ok, {
story: {
id: 1,
name: "Shire Burning",
revisions: [ ... ],
}
})
Example output:
Type String expected "Shire Burning" but got "Shire Burnin" at path: /:story/:name
Another example output to demonstrate a mismatch deep in a nested array:
Type Integer expected 2 but got 1 at path: /:story/:revisions[0]/:version
As you can see, the output tells you EXACTLY where to fix your expected JSON.
If you want to take advantage of the hash diff Rspec provides, it is better to parse the body and compare against a hash. Simplest way I've found:
it 'asserts json body' do
expected_body = {
my: 'json',
hash: 'ok'
}.stringify_keys
expect(JSON.parse(response.body)).to eql(expected_body)
end
I found a customer matcher here: https://raw.github.com/gist/917903/92d7101f643e07896659f84609c117c4c279dfad/have_content_type.rb
Put it in spec/support/matchers/have_content_type.rb and make sure to load stuff from support with something like this in you spec/spec_helper.rb
Dir[Rails.root.join('spec/support/**/*.rb')].each {|f| require f}
Here is the code itself, just in case it disappeared from the given link.
RSpec::Matchers.define :have_content_type do |content_type|
CONTENT_HEADER_MATCHER = /^(.*?)(?:; charset=(.*))?$/
chain :with_charset do |charset|
#charset = charset
end
match do |response|
_, content, charset = *content_type_header.match(CONTENT_HEADER_MATCHER).to_a
if #charset
#charset == charset && content == content_type
else
content == content_type
end
end
failure_message_for_should do |response|
if #charset
"Content type #{content_type_header.inspect} should match #{content_type.inspect} with charset #{#charset}"
else
"Content type #{content_type_header.inspect} should match #{content_type.inspect}"
end
end
failure_message_for_should_not do |model|
if #charset
"Content type #{content_type_header.inspect} should not match #{content_type.inspect} with charset #{#charset}"
else
"Content type #{content_type_header.inspect} should not match #{content_type.inspect}"
end
end
def content_type_header
response.headers['Content-Type']
end
end
For Your JSON response you should parse that response for expected results
For Instance: parsed_response = JSON.parse(response.body)
You can check other variables which is included in response like
expect(parsed_response["success"]).to eq(true)
expect(parsed_response["flashcard"]).to eq("flashcard expected value")
expect(parsed_response["lesson"]).to eq("lesson expected value")
expect(subject["status_code"]).to eq(201)
I prefer also check keys of JSON response, For Example:
expect(body_as_json.keys).to match_array(["success", "lesson","status_code", "flashcard"])
Here, We can use should matchers For expected results in Rspec