Hello and happy Friday!
At the end of yesterday’s post I spoke about wanting to wrap my mind around the three specs Adam Cuppy walked me through in our AirPair session. Today I’ll be covering the areas I didn’t understand.
First lets start with a view of the specs:
An Rspec test double is just a replica object whose purpose is to stand in for another object in a test spec. We use these replica objects to make our specs clearer when the need presents itself. Doubles are also referred as fakes, impostors, mocks and stubs depending on how they are utilized.
To create a test double Rspec provides us with the method
double. Here’s a quick example:
I’m reading The Rspec Book by: David Chelimsky for guidance about this topic and David mentions that the string in the method’s argument is optional but highly recommended because of it’s usage in failure messages.
In addition to the
double method we can produce the same type of objects with
Rspec has a method called
stub that is available for us to use when we need to return predefined responses in our spec. The
stub method takes a symbol which represents the name of the method we want to stub as it’s only argument. This can be followed up by the
and_return method, which instructs our double to return the response written inside of the
from this example we can gather that we’re expecting Faraday’s
get method to be assigned the value of a
fake_faraday_response. I’m thinking that my instruction to leave this equal to an empty hash (as seen below on line: 15) is so that we can plug in particular responses for different specs as necessary.
Subject vs Let
This is another Rspec method that I didn’t completely understand. I have been using the
let method instead of the
subject method, so I’ll cover how they’re typically used in a best-practices situation.
Here’s a quote from his post, describing how he recommends removing duplicated code from a test file he reviewed for a friend of his.
- Subject blocks allow you to control the initialization of the subject under test. If you don’t have any custom initialization required, then you’re given a default `subject` method already. All it does is call `new` on the class you’re testing.
- Let blocks allow you to provide some input to the subject block that change in various contexts. This way you can simply provide an alternative `let` block for a given value and not have to duplicate the setup code for the subject over again. Let blocks also work inside of `before :each` blocks if you need them.
- Its blocks allow you to test methods on the subject that return a simple value. The benefit of using this over the more wordy version above is that it can actually format the test output for you.
His post is a shining example, in my opinion, of how helpful code illustrations are for us newbies.
His example of using
subject to define the object he’s writing test coverage for and then allowing
let to be used as a way to change attribute values really made sense to me right off the bat. Here’s one tiny image snippet, but if you’re interested in learning how to allow
let work in harmony like this, check out his post as it’s a fun and astute read.
Running the Specs
As it turns out, after many hours of attempting to get my specs to pass, I only have the one spec passing that states the
retrieve method returns a collection of objects.
Here’s an example of my failing specs:
And so even though Faraday does have a
body method for both requests and responses, I am not currently understanding why
body is an undefined method.
I’ll show the
all method from
body call from line: 25 in the first argument of
data reveals two new errors when I run the spec:
And looking at both failures, my best guess is that the request isn’t being triggered the nil’s in both errors. I was informed that there are a few gems to help with this, I’m using two of them but haven’t gotten to the third due to working on better understanding this latest set of errors.
Here are the list of gems:
In addition to these three gems, I also found value in this RailsCast episode
and this StackOverflow where the very last answer may shed some light into my problem with not being able to access the response body.
I’ll be working over the weekend, to better understand testing for a web service response. If you have any insights or resources that might be of aid, I look forward to hearing from you.
Have a wonderful weekend!