Project Ramon

A learning journey from a Ruby noob perspective

APIs + TDD == Another Opportunity to Improve


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:


Test Doubles

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 mock or stub


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 and_return method.


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.

I found this neat explanation on a blog post by: Ben Scheirman

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 subject and 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 MenuItemsRetriever:


Removing the 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:

  1. Webmock
  2. Fakeweb
  3. VCR

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!


Categories: Newbie, Ruby on rails

Tags: , ,

1 reply


  1. Lunch Panoply: Rendering API responses and other Sunday goodies | Project Ramon

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s