Error Log: 01DEC2015

Welcome to the inaugural post of my Error Log!  Today my main task was to adapt the geolocation and geosearch features I made last week into an API consumable form.  A fun little task that definitely highlighted some knowledge gaps and common mistakes on my part!

Mistake Number One:

When I originally created the geolocate and geosearch method tests and webmock stubs, I accounted for the fact that the response body would be in JSON format so everything was good to go.  However, when I started converting things over to use the new API based app design, I didn’t pay close enough attention to how I formatted the response body in the new stubs.

So instead of '{features': [{foo: bar},{bar: foo}]}' I tried to return [{features': [{foo: bar},{bar: foo}]}] and had a delightful time trying to figure out how almost the exact same method logic was giving me a TypeError.

Thankfully Jake helped me step through the code using byebug and after some digging we saw that it was throwing the error when <a href="http://ruby-doc.org/stdlib-2.0.0/libdoc/json/rdoc/JSON.html" target="_blank">JSON.parse</a> was being called on the response which clued us in on what the problem was.  After switching the response to be returned as a String instead of an Array (as you’d expect for parsing a JSON response) it worked as expected.

Mistake Number Two:

During one portion of creating the new API version tests for the geolocate and geosearch methods I was instructed to use an assert_api_response assertion in my test to cover the response from the calls.  Having never seen this assertion before I plugged it in as I had seen in other API method tests and couldn’t quite get it to work.  After consulting the Google Machine I wasn’t able to find any reference to this assertion.

I dug down into the Ruby-Doc site, minitest’s gem site, and stackoverflow… Nothing.

In the end the assertion was actually something Jake had created and placed in our test_case/test_helper file.  I spent about 45 minutes crawling the web for something that was a quick click away in the file structure.  Once I found the method and consulted with Jake on some specifics I was able to successfully create the necessary tests.

Take Aways:

  1.  Utilizing the `Step` (s), `Next` (n), and `Error` (e) commands in byebug is incredibly helpful in narrowing down what the source of the error is and where things are “breaking”.
  2. Try to resist any assumptions made on code you’ve already written, especially once something is going wrong.  Break things down into the simplest component and step through how it “should” work to see where it actually doesn’t work now.
  3. Ruby and Rails are pretty well documented:  if a quick Google search (~15 minutes) doesn’t give you at least a clue to how to better ask the question, take a step back and either ask someone who knows your code base or do a search inside your project to see if the information is already there.  Atom Users on Mac: `shift + command + f`

 

Leave a Reply

Your email address will not be published. Required fields are marked *