Project Ramon

A learning journey from a Ruby noob perspective

Lunch Panoply: Do my Specs Provide Adequate Coverage?

Student Writing

Hello there!

Over the past couple of weeks, I’ve been trying to wrap my head around writing good test coverage for my Adapter class that communicates with an external web service.

Yesterday afternoon I was able to get my tests to pass, but to be honest, I don’t understand why they’re green, and am of a mind that I’m either receiving false positives, or testing something I shouldn’t (i.e Faraday’s/WebMock’s behavior instead of my Adapter class’ behavior). I ended up going with WebMock instead of the VCR gem, as I was spending (IMO) too much time attempting to implement a dependency and not enough focus on actually understanding and solving the challenge of adding coverage to my Adapter.

Here is my partially finished Adapter tests:

api11_ex1

And my RSpec output:

api11_ex2

Looks like I need to remove the blocks from my last two specs so they can turn yellow (Pending) instead of green (Passing).

At first I was surprised that my specs passed, but upon further search realized that to_return may be a method from WebMock and not Rspec. Rspec does have an and_return method, although I haven’t had success so far in using it. I prefer using blocks anyhow.

api11_ex3

Here’s a link to the entire page from the above image snippet, in case you’d like to further look at this.

Resources I’ve Learned From

There is good news! I have found many a resource on the VCR gem, RSpec, and related Web Service testing.
I’ll list what I’ve been reading with the hopes that they provide you insight as well:

And last but not least, here’s my latest AirPair video with Adam that I received today. It covers him instructing me about testing out my Adapter class. I’ve only been able to review a little under half of it so far, but I can already tell that I’ll have more insight from the experts to share about coverage for web services in a future post.

Enjoy!

Advertisements

Categories: Newbie, Ruby on rails

Tags: , , ,

3 replies

  1. Hey Ramon,

    If your goal is to test the ‘Adapter’, then – if I understand its role correctly, you do not need to include anything that is related to fetching data from a remote service.

    If the Adapter’s responsibility is to convert the JSON result into, say, array/enumerable collection of local objects, then I would call it a ‘parser’. And then you can spec its behavior by creating assertions about the ‘parse’ result vs. different types of output. Like the included ‘{} should return an (empty) array of objects’

    And if your goal is to have an ‘adapter’ that is supposed to unify different JSON data formats into some common format – then it’s a JSON-to-JSON operation/transformation – still something that has nothing to do with the actual data fetching.

    Let me repeat: if that’s the case, faraday/web stubbing is not necessary because it does not matter where the json is coming from. What is important is its actual parsing, dealing with corner cases etc. – the data in question then becomes more like local ‘data fixtures’.

  2. Hello Marek,
    I’m thinking that my adapter is really just parsing JSON into a collection of objects, like you mentioned. Thanks for helping me put this into better perspective!

Trackbacks

  1. Lunch Panoply: Rewriting specs for Behavior Coverage. | Project Ramon

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s