On 9 Jun 2010, at 8:04 PM, doug livesey wrote:
> It's actually a real bitch! :)

Disclaimer: after spending two days on evil evil evil Rails code, my 
therapeutic cider drinking may adversely affect the coherency of my reptiles.  
Or maybe even my replies.  Possibly both.


> I extracted an HTTParty service I'm running in a few apps into a gem, and now 
> find that I can't stub on it in cucumber like I want, so I guess, on 
> investigation into it, that the mock service approach wouldn't really apply 
> here.

Be wary of HTTParty, it encourages you to couple your own code to its HTTP 
calls via a module.  Enchantment is an anti-pattern IMO.

Also, if you've packaged your code into a gem, you're pushing the boundaries of 
what are considered "your own types".  One important mocking rule is "don't 
mock types you don't own" (probably from the original Mock Roles Not Objects 
paper[1], but I'd have to re-read it to actually check that).  This rule 
protects you from breakages caused by changes outside your own app.  According 
to this rule, you (arguably) should write an adapter layer (and integration 
tests) for every project that uses your gem, unless you have a good way of 
preventing version-related breakage.

I'm interested to know, though, why do you think the mock service approach 
wouldn't really apply to this?


> Probably a bug in the framework, as I'm on the latest betas for Rails and 
> RSpec.

Hmmm, does this relate to the above?  Which problem was related to a bug?


> I was on the verge of making some very bad decisions to get it working (like 
> using some sort of drop-in construct for the service that stored expectations 
> & recorded calls),

... that would be implementing your own mocking expectation system, right?

> so for the moment I'm taking a deep breath, counting to ten, and just working 
> around it in the knowledge that it is very completely covered in RSpec. I 
> know not having the full stack tested fully in Cucumber is going to be 
> gnawing at my conscience, though!

If I understand right (which is by no means certain), then you're exposed to 
broad interface changes.  In these situations, I like to check the assumptions 
in my spec files, as some will be stronger/less brittle than others.


And to re-reply to your original comment...

> *Really* wish I'd remembered this advice on cuke-ing services before I'd 
> started in on this one! :)

...only a week or so ago I found a piece of business advice in an email from 2 
years ago that I forgot, and have paid the price for many times over.  So be 
glad when you think of something, because no matter how late, it's better than 
blindly marching on forever!


I hope my reptiles were of some assistance.


Cheers
Ash


[1] http://www.jmock.org/oopsla2004.pdf


-- 
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran



-- 
You received this message because you are subscribed to the Google Groups 
"NWRUG" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/nwrug-members?hl=en.

Reply via email to