[rspec-users] Stubbing through multiple layers
dchelimsky at gmail.com
Sun Jan 10 08:42:41 EST 2010
On Sat, Jan 9, 2010 at 9:38 PM, Sean DeNigris <trusted08 at clipperadams.com>wrote:
> > window = stub('window', :title => "programming_ruby_1.9.pdf")
> > preview = stub('preview', :front_window => window)
> Perfect - so easy! Thanks.
> > If you have good high level specs with something like Cucumber or
> > this risk is diminished. You'll still have to change the example when the
> > internal structure of Preview changes, but you're less likely to get
> > by deploying code that passes its tests but doesn't work.
> This is something I've been going back and forth with a lot lately -
> how much implementation detail to allow to leak out into the examples/
> features. If I start using software other than Preview to read my
> eBooks, obviously all these examples will require reworking. The
> problem is magnified because I do have Cucumber tests that use the
> real Preview:
> Then /^I should see the pickaxe book$/ do
> front_preview_window = Appscript::app('System Events').processes
> Appscript::app('System Events').processes
> ['Preview'].frontmost.get.should be(true)
> front_preview_window.name.get.should =~ /programming_ruby_1.9.*
> Now details about Preview appear in Cucumber and Rspec! I'm tempted
> to put an EBookViewer role in right off the bat (similar to what Matt
> sugested), and use it in both the features and examples, but I don't
> want to add too much complexity.
I think it's clear that there is already too much complexity in this case :)
I'd go with the wrapper. It should not be expensive to maintain, and it does
give you the freedom to change the dependencies, localizing the cost of that
change to a single object.
> I'm very interested in how other people handle external dependencies
> in features/examples...
> Thanks again!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rspec-users